I'd suspect some of the things software developers see as "problems" when developing a database (such as the example in the editorial about dropping a column, then wondering why the data was gone when it was re-created,) is because software developers expect the database to behave just like the application does.

You made changes to a piece of code and it doesn't behave as you expected when checked into the full application?  Well change it back and everything is back the way it was.  Whereas working with a database is more akin to working with paper files (I know, bad analogy incoming) of patient records.  If you have someone go through with an eraser and erase the SSN from every patients file, that data is *GONE* with no way to get it back (beyond the headache and hassle of calling every patient.)  Similar to that, if you drop that information from a database table that stores it, it's gone and you're not getting it back by just re-creating the column.

The software dev expects a sort of "undo" function, like what just about any editing application has, where if you do something boneheaded, you can CTRL+Z your way back out.

With a database, your only CTRL+Z is either do your work, if possible, in a transaction without a commit at the end, or take a backup before making any changes.  Worse, from a developers point of view, neither of those are always an option...
How long do you leave your changes uncommitted (especially considering no one else will see those changes until you DO commit them,) how long will it take to run a backup (oh, you're dealing with a multi-terabyte database that you only take a full backup on Friday starting at 1800 and it runs all weekend until Monday at 0400?) during which time the changes are getting pushed out.
Sure, you could make a copy of the table or tables being modified, but how long will that take?  With a big enough table, you might be waiting a few hours.  Or there might not be enough room on the server to have a duplicate of the table, then what?

I've sort of pictured any business process that relies on a database to be an inverted pyramid.  The database is at the point of the pyramid on the bottom, because any changes there have a cascading effect up to the other tiers of the pyramid (application servers, end users, etc.)