Code change:
(also adds two paragraph breaks)
Thanks! To be completely formally correct, the term from RFC3986 should not be quoted as "user authentication information in the URI" but as "user authority information in the URI". Is that correction possible?
WFM. NAME ?
No, it isn't correct to say that it is user authority information. The purpose of userinfo in a server-based URI format (this://server/) is to supply canned authentication data for use if the server requests such information. It is strictly for use on the client-side and is not directly passed in HTTP unless that (Basic) happens to be the form of challenge requested by the server.
That would be an override by HTTP of the definition in RFC3986 then? (Not saying that is illegal; HTTP predates this URI spec.)
The generalises the constrained use for authentication by allowing the entire URI to be a server-side spec and the client to derive a hint about it as a possible authentication user. This can end any such difference in interpretation between HTTP/bis and the URI format. I do know this is a broadening of the user concept in HTTP; I also believe that this is not without a need.
RFC3986 says: Specifically, the userinfo supplies the information necessary to gain access to the identified resource via a process of authentication. That process is selected and defined by the origin, not by the URI, and the username is not an identifier of authority. Note that userinfo for http and https URLs has never been allowed, going all the way back to RFC1738. Some applications do use that syntax, internally and in a way that is not subject to the Internet standards process, so we warn about it in general.
The states RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says and continues to describe the intricacies of ":password" handling. The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated. I have written an that places it in a header with the intention of adding user names in much the same manner as host names, as a selector for a naming scope of resources. I believe that obscuring the authority for the purposes of phishing is not really mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups, but these are probably easier to remedy when credential inquiries are only made in response to and headers.
Discussed in Basel. Correcting the reasoning of why it was deprecated can be addressed editorially. Changing what was deprecated needs to be a much larger discussion and pull in the security community.

Related discussion:
text: 2.5.4. <del> The URI generic syntax for authority also includes a deprecated userinfo subcomponent (RFC3986) for including user authentication information in the URI.  Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password.  A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the </del> <ins> The URI generic syntax for authority also includes a userinfo subcomponent (RFC3986) for including user authentication information in the URI.  In that subcomponent, the use of the format "user:password" is deprecated. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" or "https" URI reference is generated within a message as a request target or header field value. Before making use of an "http" or "https" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the </ins> authority for the sake of phishing attacks. 2.5.5.