It just adds an extra layer of indirection, and another layer of processing that can go wrong. And when things go wrong, you have to dig down to the SQL level to understand it. But the table names are all mangled, which might further add to the complexity of debugging it.
One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement.
But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions.
Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”