My belief is because Access sits on the wrong side of the gap you mention. It's an SQL DB with an UI, alright, but the database is (or at least has a reputation of being) kind of flakey, and the UI exposes you to all the complexity and inflexibility of relational databases. This creates two types of hurdle. One is educational - you have to teach people basics of relational data modelling if you want Access to make sense for them. The other is operational - you can't shuffle data or table structure around in Access like you could in Excel. You can't just copy pieces of table around, you can't make rows depend on rows before them, etc.
Worth remembering is that Excel is, fundamentally, a 2D functional reactive programming REPL. Most of its users don't understand that, but they internalize the behavior. They may not know what a DAG is, but they know that updating cells will recalculate cells that depended on them. So you can't replace Excel with just a database - because half of the utility of the program is in formulas.
There is a gap - a tool is missing that would offer the flexibility, the ergonomics, and FRP capabilities of Excel, while also providing tools for ensuring data consistency and relational queries, and at the same time also making them easy for users to wield. It's a tall order.
Worth remembering is that Excel is, fundamentally, a 2D functional reactive programming REPL. Most of its users don't understand that, but they internalize the behavior. They may not know what a DAG is, but they know that updating cells will recalculate cells that depended on them. So you can't replace Excel with just a database - because half of the utility of the program is in formulas.
There is a gap - a tool is missing that would offer the flexibility, the ergonomics, and FRP capabilities of Excel, while also providing tools for ensuring data consistency and relational queries, and at the same time also making them easy for users to wield. It's a tall order.