You're adding a useless column that has no actual meaning.
Correct me if I'm wrong, but it sounds like you're saying you're opposed to surrogate keys in principle. The foreign key link to the users table is what gives a surrogate key meaning.
The downsides are that the tables referencing the user name have to store the user name (but that's probably capped at 30 characters or so)
A column holding up to 30 UTF-32 characters takes 120 bytes, compared to an integer that takes 8, or 4 if you don't expect half the global population to create an account. Even if you use UTF-8, you still have to allocate 120 bytes because code points above U+10000 (mostly emoji and lesser-used Chinese and Japanese ideograms) take four code units.
These would be more than offset by the fact that you can completely avoid a join in many cases since you already have the user name directly in the table you're querying.
And then you have to balance the practical problem that propagating a primary key change places locks in the majority of tables in the system against the cost of a join to a table that's probably already cached in all servers' RAM. In fact, factoring usernames out to a separate table could be seen as compression for all other tables, allowing more of their rows to be kept in RAM.