Softforks, by definition, result in some transactions by users who do not upgrade to be invalid.
There are more than two possible states, invalid or valid. Transactions can also be 'non-standard' meaning nodes will not create, relay, or mine them. But if they happen to (somehow) show up in a block, they'll accept them. In effect, a non-standard transaction is one doing something that a node knows it doesn't fully understand, but still doesn't break the rules... so it won't facilitate it but it also won't reject it.
The community developed softforks in modern times take the form of only making things invalid which were already non-standard. So no transactions by users who do not upgrade will be made invalid.
The miners can undo a soft fork with the support of 50% of the hashrate (although they will likely require more).
Not so-- even if 90% (or 99%!) of the hashrate were to start violating the softfork, the nodes that understand it would view it like they view any other hardfork: They'd just ignore their blocks, and to them it would be precisely equal to the miners shutting off.
My concern about SegWit is that users who do not actively upgrade will not be able to fully validate any blocks (and their included transactions) that included one or more SegWit transactions. I believe this makes these nodes to be not full with the nodes thinking they are full nodes, which I believe is very bad.
In community developed softforks nodes _know_ when rules have activated that they don't understand, and they complain to the user loudly:
Picture. If a user wanted to set up their node to just shut off when such a warning happened they could. The nodes also continue to validate all the things they always validated, anti-inflation, anti-doublespending, locktimes, etc.. even for the new transactions. Plus the non-upgraded user won't be getting any payments that themselves use the new rules, because their wallet doesn't generate addresses that use them.
So in a softfork: Everyone gets a choice to upgrade or not and can choose _WHEN_ they upgrade... e.g. at a time when its convient to them. If they use software which is customized or no longer maintained, they can still 'upgrade' it by simply sticking it behind a stock upgraded node. If they'd like to shut off at activation time until they get a chance to upgrade, they can do that too. If like most people, the changes aren't immediately relevant to them-- they don't need to worry about them... and can just upgrade when they get around to refreshing their systems. In a softfork there need be no actual split of the chain (there wasn't in the last one, for example).
Meanwhile hardforks are almost certain to split the chain even if just accidentally. They force users to upgrade at a particular time, and there is no easy upgrade: if your software is unmaintained you are just out of luck. They also carry more long term risk politically, they can effectively redefine the system-- assign ownership of coins to other parties--. There is no relatively safe do nothing opportunity-- which punishes people using alternative implementations. Look how far behind xt/classic have been on prior softforks: only implementing them months after they were deployed. A frequent cadence of hardforks would make one many development teams completely infeasible.
So in any case, I think it is clearly the case that what you propose is strictly inferior. If you'd like your node to shut down when upgrades happen, set that up-- but basically no one wants that. Losing the ability to 'upgrade' customized systems by putting them behind upgraded gateways is a massive loss of flexibility and increase in cost/risk... especially since you can't control the timing of a hardfork and can't roll it back if your deployment goes poorly.
