Spreadsheets are intuitive, friendly, ubiquitous and a terrible place to hold structured information. I say this as someone who spent the formative years of my career deeply engrossed in spreadsheets. There was a time when I could and would spend hours playing in a spreadsheet (without touching my mouse, obviously). They're great for some things but awful for a lot of what people use them for.
Let's explore why.
Spreadsheets hold information in cells. And cells can be referenced through two attributes: rows and columns. It is not defined by anything else. Every piece of information you're tracking is simply the intersection of a row and a column. B8 references whatever is in the cell that intersects columns B and row 8. Beyond "data that is in B8", sheets have no concept of what information you're putting into them. Yes you can input dates and formulas such that the value in the cell reflects what you need. But to the spreadsheet whatever you put into B8 has no additional structure, there is no schema to reference to say B8 is actually the date at which we launch this or that campaign.
So to balance that out, you start defining a schema without realising through tabs/files/headers whatever. You start by making the first row a header to define what goes into each column, B ➡ First name, C ➡ Last name of every person who's joined your last event. But then oh no, you have multiple events! So you either add a column for EVENT or create new tabs to denote new events. To calculate total number of attendees, you end up with multiple vlookups (you should be using at Index Match's) or sum ifs.
What you're ultimately creating is a spreadsheet marauding as a database! A great example of what this looks like is when we helped a car dealership migrate off of spreadsheets. They wanted to say "for this brand, in this build, for this model, in this year, it costs X or isn't/is available" but since sheets can only contain two dimensions, they had to map models as tabs and years as separate files (every year is a new file!).
Furthermore, you can't define ahead of time what values you're going to put in a cell (or a range). In a relational database, you're asked up front "are these going to be dates? URLs?" while in a spreadsheet you're free to put in whatever at any time. By knowing what's going in advanced databases can create these fancy views: calendar or kanban or whatever else they want.
Given the limitation that cells only have two dimensions with no prior on what's going into them, users resolve to layouts as an information layer. Sheets cannot "understand" calendars so you make the layout a calendar like so:
There's a whole cottage industry around selling templates to make it easier to recreate these on a regular basis!
Let's be clear, I absolutely love spreadsheets. I love a good spreadsheet, I love a terrible spreadsheet. I, like most folks, default to a spreadsheet for most things. Not only that, I also strongly believe that there are so many great use cases for which a spreadsheet is great (mainly around accounting/finance). If two dimensions is all you need (fiscal year -- month & value) then by all means a spreadsheet is perfect.
The use cases where spreadsheets should be preferred are almost mutually exclusive of those where databases are optimal. The real challenge is that spreadsheets are much better understood and represent the default for everything (here's an especially egregious case where they were used for contract tracing).
All of this is why on the stream with Ben today we won't be debating spreadsheets vs Airtable (relational databases). We'll discuss when each should be used and how to make sure we're using them effectively (but that would be a much less compelling title so we kept Airtable vs spreadsheets).