No, GP is right to ask. SQLite3 for example has WITHOUT ROWIDS precisely because these INTEGER PRIMARY KEYs are a bit artificial and they add an index (by rowid) that you might not need, thus increasing your index count by one. If you have a table of users with unique usernames, then the username is the logical primary key, and what you should use indeed as the primary key, and you should use foreign keys with ON UPDATE CASCADE and ON DELETE CASCADE (though you should allow neither renames nor deletions of user accounts, but I'm not speaking more generally).
Now, in many cases it's super convenient to have 'internal' -integers, UUIDs- entity IDs. If you're building a graph database with an EAV schema, then it's especially convenient, and it might even be the only way since different kinds of entities might have different numbers and kinds of attributes as their unique keys, but you might still need to reference them from an EAV table.
GP's is a very good question and it should not have been downvoted. It's a great question to explore.
Now, in many cases it's super convenient to have 'internal' -integers, UUIDs- entity IDs. If you're building a graph database with an EAV schema, then it's especially convenient, and it might even be the only way since different kinds of entities might have different numbers and kinds of attributes as their unique keys, but you might still need to reference them from an EAV table.
GP's is a very good question and it should not have been downvoted. It's a great question to explore.