That's no different than any other consensus rule not even just P2SH as garlonicon points out. But say, why not bare pubkeys? Or hash160s ending with 0xbeef, coins mined in odd number blocks, or coins last moved before January 13th 2013? By fixating on segwit it only shows that your thinking is being distorted by the dishonest fud of third parties.
Since miner's honest behavior is created by user's nodes enforcing the rules-- not just for segwit but for all rules, you'd have a case to make about any rule whose enforcement was less than substantially ubiquitous-- and, indeed, many users refrain from adopting new functionality right after it is deployed for that reason. But that assuredly doesn't apply to segwit now as enforcement today is very close to 100%, and in general the community adopts deployment plans for new functionality that almost guarantees high deployment ahead of activation (by synchronizing enforcement via the blockchain after a long time is given for deployment).
As tromp noted an reorg wouldn't be very relevant but on that point: Reorging back that far would be
practically and economically infeasible and if one were to do so it would hardly be any harder to reorg back out p2sh or the mining of all blocks. Also, it's typical for the activation of consensus rule changes to get hard coded in once they're deeply buried-- this is mostly done for simplicity reasons since the activation logic can be replaced with a one line check (or in some cases actually enforced all the way back to the start, if there were no violations in the history), but it also has the effect of making any absurd reorg attack impossible in theory and not just in practice which is helpful for anti-fud even if its real security consequence is irrelevant since if you're assuming attackers powerful enough to rewrite years of the chain the system already can't be secure.
This is the case for segwit:
bitcoin/src/chainparams.cpp:
consensus.BIP34Height = 227931;
consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
consensus.BIP65Height = 388381; // 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0
consensus.BIP66Height = 363725; // 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931
consensus.CSVHeight = 419328; // 000000000000000004a1b34462cb8aeebd5799177f7a29cf28f2d1961716b5b5
consensus.SegwitHeight = 481824; // 0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893
Looking it up, this was implemented in
PR16060 in 2019 so anything running that code or later wouldn't fail to activate segwit enforcement at that height even if a fairytale reorg were generated, making the OP's specific attack technically and not just practically impossible.
