This being said, Excel is most likely the most widespread tool for anything that involves office work. I've seen entire financial algorithms being implemented using Excel alone.
ISP agents would come to your house to collect your bill. If someone didn't pay, the agent would flip a cell in their excel row. And that would trigger that person's internet being suspended. Sometimes they would flip the wrong person, and you had to call them, and they would fix it.
EDIT: As many people have pointed out, Excel did suppport collaborative editing at the time.
Now, "supported" does not mean it was in any way good idea, or that it resembled how collaborative editing works in things like Google sheets or O365. Conflicts, deadlocks, etc were common - it's even why I built my first Rails app - we were given excel sheet and asked to do data entry on it over network from multiple machines, I didn't trust it despite a demo of it working and built a quick and dirty webapp.
(Source: I built one of those during my school holidays but I didn't get paid and I didn't have the balls to ask for payment)
1) it's not clear what it does
2) it doesn't show them all the data at once all the time
3) it doesn't let them write formulas to work on the data
4) the few that saw Access in action say that they have to call a programmer to do what any Joe can do in Excel
So whatever Access is doing Excel does it better and they can't understand why Microsoft developed a crippled version of Excel to manage tables of data. At this point I almost don't understand it myself anymore despite having seen all the years of Access and Excel ;-)
I run it on Windows Server and paid somebody to write the Windows service to manage the Excel sheet. I can't remember which language I used for the web service itself.
They eventually gave up, commercial problems, not technical ones.
Since that will nerver happen, someone needs to make an open source speadsheet that runs on postgres. And yes, it does have to be open source because otherwise nobody will learn it. And it needs at least 80% feature parity with excel.
That combined with some thing like Office365 or Dropbox type service and we have what you might be describing.
spreadsheet gui <--> database <--> application
The spreadsheet does simple data manipulation and acts as a GUI
The database can be mysql, postgres, sqlite (even JSON...)
The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do.
This stack could solve, in my opinion, >50% of all business software.
I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.
I'm confused. I have written Excel workbooks that write (insert/update/delete) to a database using VBA w/ ODBC.
Better would be something like Excel but that works P2P like SyncThing, or even directly using SyncThing itself.
I don't think it would actually be too hard as long as you didn't need truly realtime collaboration if you used file sync as your backend, and gave up on the 2D sheet model in favor of a table/records model that lends itself to conflict free operations instead of edits to specific numbered cells.
Guess which one you would see more of.
Still there are 100 faster, more efficent and less error prone ways to get data from A to B than printing it out and having another guy type it.
I've done some industrial automation in Excel/VBA. The company wanted it that way. Their whole IT department did everything in Excel/VBA.