Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare.
Well OK then. Using a configuration mechanism like ACL's that cannot be distributed to multiple users (like editing a directory can) is, in a word, stupid. It is also unscaleable and will become an administration nightmare. And authorisation is not (or SHOULD not be) the job of ACL's its the job of authorisation modules, which nssov is.
Being forced to give admins who simply want to be able to change access to a random host in a centralised server root access to what may be a critical server with other sensitive data on it is simply wrong.
The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful.
Then don't sell it as one. You claim pam_ldap compatibility but that is false. The user docs also aren't nearly as strongly worded, saying that the hostserver and ACL's is preferable, not that userhost is deprecated.
A flexible solution gives administrators the opportunity to use the tool in ways you haven't conceived of because it works for them and their environment. A ridgid and dictatorial tool forces people to do things one way and one way only. I have worked for one of the larger software companies and can tell you that the ACL mechanism would scale orders of magnitude worse, and they did, in fact have authorisation info stored in user and host attributes because that was the only way to delegate responsibility to multiple groups.
PS, you may wanna consider dropping the Ulrich Drepper attitude. When a contributor, especially a first time one, who has gone to considerable lengths to follow all the guidelines and do things just your way has, as his first experience someone calling things "stupid" ... well, that will thin the development herd considerably.