I have seen quite some "project specific extensions" from various developers and never saw the"user_" prefix, even though the documenatation instructs to use it:
Project specific extensions (not generally usable or shareable): Select any name you like and prepend it “user_” (which is the only allowed use of a key starting with “u”). This prefix denotes that this extension is a local one which does not come from the central TYPO3 Extension Repository or is ever intended to be shared. Probably this is an “adhoc” extension you have made for some special occasion.
But developers tend to use "client_usecase" or just "usecase", if my perception is representative. I was told that "user_" enlarges several things like database-table-names unnecessarily and the extensions's namespace (vendor-name/extension-name) is more important than the extension-key and this part of the documentation may more or less be a remnant of the past.
My concern was, that such an extension key could conflict with other extensions, f. e. the Extension Manager may try to download translations and suggest to download updates, problems with dependencies may occur, or TYPO3 Hosters may install security patches, etc. I'm personally using this prefix in my user_site extensions (project specific TS and Templates) for several projects and was expecting some conditions in the core, f. e. that the Extension Manager skips any translation updates for this extension, but I couldn't find anything. Maybe I should suggest (forge) to exclude such extensions for version and translation updates and highlight it as "project specific" in the Extension-Manager-list.
I thought that there are only two options: register an extension key or use the "user_"-prefix, but this seems to be outdated, or at least commonly ignored.
Is there still a benefit of using such prefix and is this the way to go, or will the extension key registration possibly be replaced by something like a vendor-name TER registration in the future?
The documentation always was an recommendation - and (nearly?) no one used extension with a key beginning with user_.
It was an recommendation to avoid conflicts like you described. But the conflicts were avoided with prefixes of programmer, company or client (which is like a vendor name).
In the old days not only tables were prefixed with the extensionkey, but also additional fields to other tables. especially if you used the kickstarter/extensionbuilder.
Today we use namespaces to avoid conflicts with class names, but still can get conflicts with extension keys as any vendor names does not count if the extension is installed beyond typo3conf/ext/.
The folder probably could be renamed, but having the same kind of records (with different fields) in tables with identical names could break the system.
Example: don't try to introduce an own extension for news named news ;-)
On the other hand you might get fields with identical information but different names:
latitude/longitude, lat/long, lat/lon.
And what about fields which are named identical from different extensions which use different data representations? time as string, unixtimestamp, time, ...
Conclusion: you can't avoid all conflicts, and being aware of possible problems might help to avoid it with some smart assumptions.
The auto-update for extensions can only occur with a composer-install, but there the vendor name is important. In an installation without composer you might get an extension from TER where the extension key is identical to an own extension, but it should be known if the own (local) extension has newer versions in TER. especially if the extension has a prefix from author, company or client.
Be aware that extensions are available not only in TER. With composer and packagist extensions can be stored anywhere.