bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your /etc/passwd file must have passwords. These are the administrative accounts — bin, daemon, sys, uucp, lp, and adm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-free bin account is extremely useful for a system breaker.
— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
