Programmer Humor

He's in the north pole, so probably Canadian dollars, Russian rubles, or Danish krone (Greenland) 

Only the nice ones, the naughty poor children get free coal

Your view of databases is indicative of a different issue I tend to rag on about. This is by no means intended to discredit your feelings about it – they're perfectly valid and understandable given your own background.

The issue I mean is that many things I consider easy to understand (with the caveat that my own familiarity will heavily skew what I consider "easy") or at least basic useful or important knowledge are often misunderstood.

This should be a fairly simple fix with some superficial survey style trainings, which obviously requires both the time investment and the willingness to engage with the matter, neither of which is quite as simple as I'd like it to be. The biggest hurdle, in my experience, is finding a good teacher that can effectively simplify and communicate that surface-level overview.

To pick some examples from your comment, assuming we're talking about SQL databases:

First off, you're correct that, without training or expertise, opening and interacting with databases can be tedious. Some of this can and should be simplified (keywords: views, procedures built by more experienced users), and there are graphical tools for many database types too. Even with all that, it'll never be quite as "trivial" as spreadsheets.

The data shouldn't be cryptic. You define tables, much like you would in excel, except you have to be more explicit about their contents – Numbers? Text? Dates? Money? If you give your tables and columns reasonable names, this shouldn't be too obscure.

You're correct that, without some frontend providing guardrails, it's easy to screw things up when editing or deleting data. I also think it's easily avoidable with some simple habits: Before you update or delete, run a SELECT query with the same filter criteria to make sure you've only got those entries you actually want to edit.

You can also use transactions to "prepare" the change and only actually "save" them if it worked correctly. That's three extra commands, with slight differences based on your SQL dialect, but the general outline is the same: Begin / Start your transaction, do your insert / delete / update, select to make sure the result is what you intended, then either commit (if it's correct) or rollback (ig it's not).

Modern databases should be resilient against corruption. Backups are usually simple, built-in functions. Migrations are often possible through simple wizards.

None of this will make databases simpler than (or even just as simple as) spreadsheets. The reason you'll see experts advocate for them anyway is that the added effort (ideally) is rewarded with more reliability, more powerful functions and better interoperability with other tools.

As someone working with (specifically, reading and processing) structured data, databases generally provide some degree of clarity that Excel sheets don't. I'll be ever so grateful for you if you do use them.

But I can't begrudge anyone for choosing the easier (in the short term) way.

As someone who interacts with databases regularly... Yeah, that sounds about right.

I was recently working with another team's feature to handle data retrieval for the end user, pretty front end but it was far too tightly coupled with db management concepts. How is a non-technical person supposed to know the difference between an inner join and a left join?

Not too long ago I suggested using cross apply to a senior dev I work with and they admitted they weren't sure what that does or how to use it. People who don't regularly work with databases have no chance.