Well, well, well... Sensitive topic you're bringing here. The question is perfectly legitimate and the answer isn't clear. I will give the explanation I would give if I tried to defend Gasper and then what I think.
Gasper Defense
In distributed systems, there is a famous dilemma called the CAP theorem. Apply to blockchains, it states that it is impossible to guarantee both consistency and availability in case of a network partition¹. Consistency means that you don't have conflicting blocks and availability means that new blocks can constantly be added.
Thus, when building your protocol features you must favor one over the other. For instance, Bitcoin has chosen to be available at the expense of safety. This makes Bitcoin prone to forks, and indeed it happens frequently that two miners propose a block at the same height leading to one of the blocks becoming an orphan block.
Ethereum also made the choice to favor availability. Coming from a previously Proof-of-Work setting this makes sense. On the contrary, Tendermint and other blockchains have chosen to have a BFT-like consensus (Byzantine Fault Tolerant) which typically favors safety over availability. This difference makes a protocol like Tendermint not usable for Ethereum.
The choice is to favor availability for Ethereum, but they also try to ensure safety (when there is no network partition). To do so, Vitalik came up with an interesting method called Casper, which as you can see goes back to 2017. Gasper is the next step of that which includes Casper directly in the protocol, providing the benefits of safety in times of synchrony (when there is no network partition) while keeping the benefits of availability.
IMO
The first problem with Gasper is that it is way too complicated. Vitalik admitted it himself:
the final output was pretty complex.
One could even argue that several interesting propositions were better alternatives for solving Ethereum's goal. These two propositions were at least in part inspired by Casper. But in my opinion, Vitalik pushed for his own ideas. It is true that it is weird to now mention single-slot finality as a new objectify when several blockchains have a protocol doing exactly that. And those protocols are not so complicated and could have been twisted to fit Ethereums needs.
I think there is also the fact that at the beginning the goal was to have every single validator involved in each epoch. This is something that BFT usually don't do, they have a restricted quorum that changes from time to time. No other protocol has that many validators participating as much, that in itself was a challenge to accomplish.
In the end, the fact is that Ethereum managed to go through the Merge and is still working. Now Vitalik realizes that its goal to have every validator equally involved is not compatible with single-slot finality and expressed it. It is not the next priority but surely people are working on it, you can't help but be excited about Ethereum's future always evolving.
- If you look at the CAP theorem definition you will see they don't talk about blockchain because it is older than that. The terms can change a bit when specifically talking about blockchain. For blockchains, you often talk about safety or liveness, but you can basically transpose safety with consistency and liveness with availability.
