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?

Table partitioning does nothing to solve the performance problems of joins of very large datasets. Materialized views can help but they are not a panacea. You have to trigger the updates yourself, and because they are updated asynchronously, you will not have a consistent view of your data. E.g. you could write a row to the database and not see it updated in your view for minutes.