"Using a relational database as a flat data store? Super bad."
Are you referring to the users table? I am not too accustomed to using flat files, so I am curious.
If you tried to delete the table, it would fail stating that a deletion would violate the constraints assuming you didn't have deletions cascade automatically (which would be equally bad).
On the other hand (and it probably happened here) there will be one table with all sorts of data bolted on.
So say you want a user to have multiple pieces of armor (following the spirit of this post). You should have an armor table and a user to armor many to many table. But instead you just add an Armor column to the user record and create a new user record (with a the same username for example but with a different unique artificial key) with the new piece of armor in the armor column. Then to retrieve it you just select armor where username = whatever and iterate through the list. Adds and deletions are just as easy. So, why not? Well, duplication of data, for one thing. And no referential integrity protection for another. Delete a username and everything is deleted. Forget a where clause and you are sunk.
Working in production database? Bad.
No backups of mission critical data? Super bad.
Using a relational database as a flat data store? Super bad.
Honestly...I think this company deserved what they got. Good thing the author got out of there. Hopefully in their new position they will learn better practices.