There are at least two use cases where a comment column for dba_users or table dba_user_comments is useful. (1) Many shops use one database for multiple applications. (2) Legacy client and server applications store individual users inside the database (i.e. not that end users are rows in a table called e.g. app_users). When the number of users/schemas/accounts in the database grows, it's not always obvious to find which app uses which user in case (1), or which user corresponds to which real user in real life in case (2). Our shop uses a combination of a text file maintained by DBAs and the profile column of dba_users for such identification. But a VARCHAR2 (not LONG please) column for dba_users or a table dba_user_comments would help a lot. After all, we have had xxx_tab|col_comments for well over 20 years (and yet not many shops use them).
A general comment. It's true that any software has its own priority in implementing new features. Normally, critical, much demanded, features are near the top. But prioritizing solely based on criticality or desirability is not right. Instead, the ratio of criticality to ease of implementation should be the guidance. Adding a comment column to dba_users (i.e. sys.user$) is not critical or much desired. But it's easy; it won't interfere with any other part of the data dictionary as messing with other internal tables would do. Alternatively, adding a separate table e.g. dba_user_comments is fine too, which is even less intrusive to existing data dictionary.