This is a great illustration of why most database designs are so bad. Hear me out.
I think you can imagine a situation where you end up with a table named "Salad" (or "Salads", or maybe even "SALADS" if you're nasty). Perhaps you're building a database application for a restaurant or grocery store, or some sort of meal planner or nutrition tracker.
Salads are obviously Distinctly Different Things than Meats, Dairy, and Drinks, so those are separate tables. Except, invariably, you run into the exact pointless arguments being made in this article: you cannot actually define the boundaries of a salad, because, like almost every noun, "salad" is an address in conceptual space. It's a way of summoning a group of ideas into a conversation so that you can communicate, not a way of Doing Exact Math as CSMastermind eloquently pointed out in another comment. You can start at this address and adjust it with modifiers like "fruit" or "Caesar". You can move arbitrarily far: "I had a fruit salad for dinner, except the fruit was all fermented and smooshed up into a bottle. It was wine. I had wine for dinner."
So you end up with records that are kinda-salads and you don't know what table to put them in, and you also end up with wanting to say a whole bunch of the same things about Salads that you want to say about Pizzas and Sodas too. So you end up with both poor cohesion and high duplication. Your tables mostly share the same 12 columns and you don't know where to look for things.
"But I would never make a 'Salads' table," you say, "that's far too specific!". But you do: you make an Employee table, or a PcrTest table, or an ElectricalSubstation table. Or perhaps those should be more general: "Meal", or "Person", or "Analysis", or "Facility"! But now your SELECT results look like a checkerboard of NULLS and real values as the sub-definitions show up anyway. And even then, you still run into cases that somehow don't fit: we're making a lot of these kinds of Facilities, so we want it in the Facility table, but it's not a real facility, it's a template facility! You've weakened your definitions for not much gain.
And all of this is assuming you already know everything about the domain, but you don't! You're exploring, discovering, iterating, beta testing, pivoting. You make database tables by identifying the nouns that your SMEs use when the SMEs themselves can't fully define them, and then you get annoyed at the inalienable property of language that it is resistant to strict definitions, and briefly wonder whether we'd all be better off speaking Lojban. Then you wonder about abandoning this restrictive idea of "schema" and go NoSQL or key/value, until you realize that you still have a schema, it's just now no longer enforced or supported, and you go back to relational SQL with a few remaining key/value pair systems still jammed in here and there.
So you start from faulty assumptions, make choices you don't need to be making, develop an inflexible design, and end up having pointless arguments like the one in this article -- except instead of being recreational lunchtime arguments, they are ones that determine the failure or success of your business.
Stop defining tables based on the first nouns you encounter. Nouns do not work that way. You will never be able to define them. Instead, define tables based on statements you want to make about your entities. Every time you come across something you want to write down -- a person's name, a place's address, nutritional information, a SKU -- find a table for that. Keep things cohesive: Full Name and Address don't belong together, because many things have one but not the other. Stop trying to decide whether a given entity is a "Person" or an "Employee" or a "Salad" or a "Facility": you don't need to care! All you need to know is what you want to say about it.
This has a ton of design implications that could easily fill a textbook, but it does work. You can actually have a flexible database design that isn't full of NULL checkboards and the same 12 columns in every table. But you do have relegate these pointless Salad Theory-type arguments to the lunch hour, because you'll instead find yourself talking about actual useful things during design meetings.