That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. If there's going to be an intermediate release (6 months?) which lays the groundwork for future rule changes, it helps more.

It would be good if getblocktemplate was updated at the same time to serve errors if the fork warning is active. I'd hope miners have some way to automatically handle IBD/getting forked off the chain, but I guess some (newer) pools might not, and refusing to serve work should be the safest option that shuts them down.

 

P2SH was a soft fork and the sky did not fall, but miners did lose money and waste electricity mining blocks on the wrong side of the chain:

Presumably they didn't notice for longer because it looked like a run of unusually bad orphaning luck. It seems safer to have a clean fork, with alerts telling people during the lockin period before new rule enforcement starts (and possibly automated termination if there's no upgrade by the flag day?). Miners who ignore it would still risk losing money, but merchants who wait for a block at least would not be at risk.

One open question is how can you actually trigger a hard fork? Coinbase scriptSigs are not executed, so putting some ignored but failing opcode sequence there wouldn't work. One possibility would be to have a special invalid tx in the block that marks the start of new rule enforcement. New nodes would know to ignore it. But this risks corrupting block explorers. Alternatively the coinbase outpoint structure could have its hash set to 1 instead of 0.