Yeah, it does make sense. I do agree that some safety guards could rely on some sort of centralization of power; as you pointed out, it is not widely accepted. In practice, though, I do see many projects relying on some level of centralization. In many occasions, it is very hard to get a fully decentralized system right from the start; this is generally a long engineering process that takes time and effort. As a compromise, due to budget and time-pressure, projects tend to accept (at least temporarily) some level of centralization.
I want to point out something to your attention. The attack you had mentioned is in theory possible to be handled, but it requires some level of monitoring. For instance, if you continuously monitor the transactions in the mempool as a means to identify transactions that could potentially harm your smart contract (e.g., as it occurs with flash-loans), then whenever a malicious transaction is seen, you could immediately send another transaction, giving it higher gas to effectively front-run the malicious transaction. Among other things, your transaction could black list the sender of the malicious transaction (assuming your contract supports this operation) or pause the contract altogether.
What do you think?