Author of the original post here. Any time you come in new to a system and just assume the columns are self explanatory you often make a wrong assumption somewhere along the way. Being explicit is not much more effort to make it safer when analyzing or working with the data.
As for a 'data' column name for hstore. This is something I've often talked about, hstore is a key value store. The big value of it is adding and removing things fluidly over time, for that reason data can be a good a column name as any in certain cases.
Absolutely could not agree more. The thing that even clearly named schemas, tables, columns, etc. miss are context and intent. If you have that context already you probably don't need much by way of documentation. But as someone that gets called into clients to work through their databases, I spend a lot of time trying to figure that context and intent. If it's documented, that learning curve is reduced greatly.
I usually do these comments on all objects regardless of how obvious the names and code may be. If even only for the reason of ensuring that doing this discipline remains second nature. I also like to remember that I'm not doing this for me, but rather for the client's team and others that come after me to work on things.
It's always nice to have a post explaining that you can comment in SQL. Most people are not aware of this, and it definitely helps when reading a DDL.
I have to agree that sometimes there are superfluous comments that harm more than help, since they add nothing to clarify the purpose of the column but consume your time. For example, in your post, the comment "required first name of the user" for an attribute called users.first_name adds no extra information. I'd also avoid using "required" as part of the comment, as that's implied in the NOT NULL constraint. However, other comments are very valuable, like the one for "created_at" or "data".
Regarding having a last, nullable "data" hstore or jsonb column, I think it's a very good practice. A nullable column is almost always free (takes no extra disk space) and allows for storing information without a prior, clearly defined, or variable schema, without having to be ALTERing tables frequently, which usually is a challenge on its own.
As for a 'data' column name for hstore. This is something I've often talked about, hstore is a key value store. The big value of it is adding and removing things fluidly over time, for that reason data can be a good a column name as any in certain cases.