Using smart contracts, people are creating cryptocurrencies within an Ethereum network. Sort of a blockchain-within-a-blockchain. Right now, Polygon is a popular alternate Ethereum network for doing these.

The problem of course, is that once these contracts are published onto the network to create your new cryptocurrency token, it's very difficult (perhaps impossible?) to update them. And of course, if someone finds a vulnerability in one of the contracts and exploits it, it's game over. There's no reversing the transfer of tokens.

So to give a more explicit answer to your question, it's not a problem with Ethereum, but a problem with the contracts people are writing on the Ethereum network.

This is most likely a problem with this specific smart contract, from what I understand, if the EVM on the "winning" miner were to produce a state transition that did not faithfully follow the SC, that block should be rejected.

Polygon is a little different, due to its proof of stake system, where there is no "winner" and the validators (Heimdall instances) "check" the work of the actual block producers (Bor instances). It also has a slasher-like element where only one Heimdall instance needs to prove that a block is incorrectly executed for it to be rejected, so a malicious actor would need to compromise all active Heimdall instances to be able to lie.

It was an issue with a specific contract, not the contract VM or the chain itself. It's absolutely a problem for other poorly written contracts, but not a systemic problem for all smart contracts.