An interesting (IMHO) historical tidbit:
Way back in the good old days, when Unix and it's contemporaries were actually used as mainframe-class multiuser timesharing systems, a facility to inform users of news and updates was a basic necessity, rather than these days, where it has apparently degenerated into another revenue source, used for spamming you with advertisements delivered through ill-conceived MOTDaaS (MOTD-as-a-Service) channels.
It seems the first system to have a standard and well-thought-out MOTD system shipped by default, was, of course, Multics - the ancestor of most good ideas in use today. Here is the info page for the print_motd facility:
:Info: print_motd: pmotd: 03/17/87 print_motd, pmotd
Syntax as a command: pmotd {control arguments}
Function: prints out changes to the message of the day. The default is
to print changes to the system and user_project message_of_the_day
segments since the last time the command was called.
Control arguments:
-all_text, -all, -a
specifies that the entire contents of the system and/or project
message_of_the_day segment be displayed, regardless of
whether or not any of the messages in the segment have been
previously seen.
-current_project, -cpj
prints lines from the message_of_the_day segment for the project
on which the user is logged in. If the project administrator has
not created a message for your project, nothing is printed.
(default)
-new_text, -new
specifies that only unseen messages in the system and/or project
message_of_the_day segment will be displayed. (default)
-project projects, -pj projects
prints new or changed lines in the message_of_the_day segments for
the named projects. A warning is printed if there is no message
for one or more of the projects.
-system, -sys
prints lines from the message of the day segment created by the
system administrator. (default)
Notes: If -system, -current_project and -project are not specified,
then print_motd prints lines from the system message and from the message
for the current project. If one or more of these arguments are given,
then print_motd prints lines only from those messages.
For comparison purposes, copies of both the system and project motds are
stored in the user's default value segment. print_motd will create the
value segment if necessary. The project motds have the name
project_motd.PROJECT._ where PROJECT is the default user project or a
project specified by the -project control argument. Project motds will
be created by a project administrator and placed in the project directory
with the name >udd>PROJECT>PROJECT.motd with an addname of
>udd>PROJECT>PROJECT.info.
The first time that print_motd is used for a specific project, it will
print the entire contents of the message of the day segment. Subsequent
uses will default to print those lines which have been modified or added
to the message of the day since the last use of the command unless the user
specifies the -all_text control argument. Since a copy of each motd
segment is stored in the user's value segment, project administrators
should keep the size of the project motd segments to a minimum by deleting
older messages as they expire.
Unix, as we all know, started life as a minimalistic stripped-down system imitating many of the Multics facilities, but running on the comparatively cramped 18- and 16-bit DEC PDP machines, rather than the more powerful (and much more expensive) 36-bit Honeywell hardware. Instead of a "complex" news facility, most Unix systems simply displayed a text file, usually /etc/motd, to the user after login. Sometime in the 1980's, Bell/AT&T decided to expand on the system, essentially depreciating the motd file and introducing "news", which re-implemented most, but not all, features of Mutlics' pmotd. Judging from the comments in the System V source code, this was introduced sometime in 1983 or 1984. Here is the AT&T help page for the System V news command:
news: Description
Syntax Summary: news [-a] [-n] [-s] [item_name ...]
where: item_name is the name of a file in the news items directory.
Description:
news is used for reading news items posted on the system. Use news to
read files from the system news items directory. news followed by
<item_name> prints the specific news item from the file with that name.
The options allow you to check the names of all current news items, the
number of items there are, and whether or not you have already read them.
news: Options
-a prints all news files regardless of modification time.
-n prints the names of current news without printing contents.
-s prints the number of current news files that exist.
news: Examples
news
Prints all the news items on the system that you have not already read.
news reorg
Prints just the news item "reorg".
However, as history would have it, most of the additions found in UNIX System V and later Research UNIX (8th through 10th Editions) never made it back into the BSD releases, and most (non-BSD) clones chose V7 as their starting point, leaving advances - like STREAMS, Blit support, Sam, Mk, rc - along with the "standard" utilities like "newer" and "news" mostly unknown today.
Obviously the "news" command can be trivially reimplemented using any scripting language or the shell, but, here is AT&T "news", minimally modified only for necessary clean-up to get the early 1980s C to compile on your modern Linux and BSD systems. (Copyrights have been left intact - and will be removed upon proper request - however, it is widely available on every Bitsavers mirror.)
I've tested it on Linux and OpenBSD only, and to avoid massively overcomplicating things, the Makefile has a few variables you might want to tune for your specific environment. It would be a trivial hack to add Multics-style group-specific news as well.
I'd imagine a particularly transparent and Unix-like way to accomplish this would be to leverage the Unix the permission system, with group-specific news items group readable, and having the “news” tool silently ignore any news items the user doesn't have permission to read.
Why was this not widely adopted, I wonder?
To answer your last question, simply a matter of scale. Whereas Multics systems were typically campus-wide or company-wide (Ford) or served multiple Universities (AUCC), Unix systems were typically departmental minis where people could just talk to each other.