I'm just offering the context from which weird stuff happens. And the answer isn't always as easy as: put it in a database.
The context, the processes (or lack of processes), the decision-makers, budgets, timelines, they all play a part in the outcomes.
One thing Excel is extremely bad at is reliably importing data from CSV. It's unbelievable what errors you can get if you're not extremely careful.
They can do it by themselves with Excel. Can they do that with any other software?
Not many people would be able to do complex calculations in an RDBMS, especially if it requires joins or grouping. But many more are able to use a GUI tool to create a single database table and import some CSV data.
The recent UK disaster wouldn't have happened if the data had been imported into Access or SQLite instead of an Excel sheet.
Of course it's not a panacea. Badly designed databases can be just as error prone as Excel, but they have different error modes.
But when developers complain they have to learn domain specific items, people say the shall keep up with the times. but suddenly the analysts and the others are exempt from this?
This is so frustrating because I've worked in small departments in an international company. Our problems were too small to get consistent, needed help from IT and we weren't important enough to get one of the limited licenses to the fancy reporting system.
Ultimately, there's all this bad talk about evil Excel, but we get no help or other resources.
And what about all the junk reports that were coming out of the company database that no one wanted to spend the money to fix?
THE ONLY VIABLE ALTERNATIVE WAS EXCEL.