This was my reasoning behind a spreadsheet prototype backed by kdb+ and the q language (which is a superset of SQL): https://github.com/srpeck/kxl
There is value in this simple combination, but tons of work required to gain feature parity and market share from Excel. I think the latter is why research in this space is lacking.
Because now you've removed the primary thing that makes Excel so popular: its approachability. You don't have to learn anything special before you can start getting value out of Excel. You don't even have to understand how to write a simple formula! It's useful even as a simple, dumb rows-and-columns data store.
This is how Excel makes so many people into accidental programmers: they start using it in a naïve, low-knowledge way, and then eventually wonder if there's some easier way to do what they're doing. ("I'm tired of adding all these figures up by hand. Is there some way Excel can do that for me?") So they dip a toe in, learn a little bit, and become even more productive. Then they repeat this cycle over and over, and years later they have become Excel gurus without ever actually setting out to.
(Of course, the downside to all that is that they've now built a ton of stuff in Excel in hacky, incremental fashion, and are quite possibly using Excel to do things a real database would be much better at. But they don't know that -- and besides, if the only tool on offer was a real database they probably would never have gotten around to building anything at all.)
Anything with a "real programming language" is going to lose these people, because learning that language is a big chunk up-front work they have to do before ever seeing any benefit. Anything that wants to compete with Excel needs first and foremost to offer the same kind of immediate productivity benefit and gentle, incremental learning curve to reach the Excel audience.