Yeah, I don't know about other fields but the way "simple", "complex", "clever" are used in software is so backwards and inconsistent. These terms mean nothing in tech and we should excise them.
Much of what MacKinnon is referring to here would be seen as simple, complex, or clever by many people. He advocates for static languages but when he does so he talks about "useful" and "tradeoffs", which are radically better terms if you actually want to discuss these topics.
One case he talks about is an abstraction over Mongo, but then the queries were designed for mongo. Is that an issue of simple or complex? I have no idea, I'd say neither. The issue was that you abstracted away essential properties of your system.
TBH, despite the title, what he says is seemingly radically more about tradeoffs and actual concrete ways to write software - I didn't hear him talk that much about "simple" or "complex" and what he said were instead reasonable cases where things went right or wrong, or his more nuanced opinions on why certain techniques and technologies lead to better outcomes. Ultimately any productive conversation ends up that way, if you find yourself saying "simple" or "complex" a lot in a conversation then you're probably doing it wrong.
Legibility and domain modeling get mixed up with business models and incentives, so good-simple just isn’t the same thing to the people paying for simple and the ones fascinated by simple,
What mongo solved was user adoption and being legible to a specific type of person making a business decision with very high LTV (a web developer handling JSON and needing a scalable database for it they could dump it into). It’s aligned with the purchaser’s needs and incentives and honestly isn’t awful even if it does end up becoming enormously expensive later, because you might just really need a database your team understands and can use asap.
Mongo churns because what’s legible to a purchaser and what captures the essential qualities of some kind of application domain or abstraction are different things. Once immediate growth is covered and you can afford someone who knows a lot about databases to work on yours they’re like “what the hell” because it turns out that it didn’t do what you’d typically consider the bare minimum of a database: https://news.ycombinator.com/item?id=40901573
But what is consistency, and how nitpicky are you about it if your problems seem to be solved well enough that something’s no longer a problem? I like software because there is a certain mystique behind understanding things like “public key cryptography would be useful in any universe with numbers” or “you really couldn’t improve on TCP for what it does”, because these tie in to real world problems but are also universally applicable, so distilling them to their essential form reveals a kind of API of the universe. But you don’t need that to get value from software and computers, you just need to solve your problem, that being, you need a database now or you lose a sale. What’s “simple” or even what counts as a database isn’t legible between the two.
Tech has a lot of money wrapped up in it so there’s a lot of attempts at capturing mindshare and defining things because the payoff is enormous. It just doesn’t sound fun to me to build up a house of cards selling a database that isn’t actually a database and deciding to figure out that whole database thing later when churn, CAC, LTV, and market adoption metrics tell me to. But also, customers really did need to shove json into databases and weren’t too picky about the particulars. So fuck it, this is a database.