I would turn that round. We shouldn’t introduce a soft fork rule that can be broken by accident, unless there’s a really good reason to. The original motivation for the timewarp attack was to prevent a very destructive attack that could happen in a matter of weeks. That doesn’t require a 600 second limit.
If the timewarp attack had been fixed with a 24 hour limit, I don’t think anyone would have proposed a subsequent soft fork to lower it to 600 seconds.
Above I linked to two actual mining pool software bugs that caused invalid blocks on testnet4 because they were using the system clock instead of the block template nTime. Bitcoin Core itself (briefly) had a bug where it could accidentally violate the timewarp rule. So that’s three real bugs found with minimal testing. We have no idea how much (closed source, unmaintained) mining software is out there, and we can’t expect every pool, individual mining farm and solo operator to thoroughly test their entire infrastructure on testnet4.
Most modern soft forks have used standardness to protect miners against accidentally producing an invalid block if they don’t upgrade their node. They also need to upgrade their node to not accidentally mine on top of an invalid block. And as a community we rely on a very large majority to upgrade their node in order to safely deploy the soft fork network wide.
The timewarp fix with a 600 second limit deviates from that because it requires miners to also check their entire stack of mining software. Whereas a 150 minute threshold only requires them to upgrade their node.
Miners should of course, regardless of the soft fork, check their mining software for the above bugs (they only became visible because on testnet4 the 20-minute-difficulty-1 rule is exploited more aggressively than on testnet3, pushing MTP structurally past wall clock time). But that’s an orthogonal issue.