More importantly here normalising the database has conceptual and interactive overhead: in the original model all spell properties are in a single table which makes import/export and devtools easy, while the normalised schema splits the same thing over 3 different tables (at least, not sure the example is even complete).

I see it as a case of YAGNI.

Also this specific issue likely wasn't a problem of mass: the number of spells in the game is not that high, even today. The issue was throughput, IIRC they had high expectations and they got 10x as many signups as they'd expected.

I'm yet to have the privilege to work on a database which I would call truly "massive", so I'm oblivious to how things work in such environment in reality. I've seen the question and the answer you've given repeats many times, but aren't there exists a plethora of tools like table partitioning, materialized views etc. to allow one to have the database in a normalized form and run it fast? Don't they work in practice?