Summary
In Unix, Linux, or BSD systems:
Besides private-key or password files, user-private content, or any custom-application-specific reasons (like serving a database of private information for users or automated processes, internal or external), why disable other access file permissions (eg: chmod -R o-rwx <file/directory>) for OS-system-installed files, related configuration settings content (often found in /lib and /etc) and additional, common/standard places?
Please read and understand this related question ("Why do many linux files have others=read access?") and its answers before commenting or answering.
More details
What general reasoning or "best practices" apply to most any system, particularly any system providing a service (popular examples include but not limited: DNS, SMTP, IMAP, HTTP, and their secure variants) on the public Internet?
Note that we are focusing more on system files and less on application-specific or user-private info (like many files/dirs found in /home).
My team is particularly interested in general paradigms/best practices for /etc, but the question applies to any part of any filesystem created in a Linux/Unix/BSD install.
In general, we'd prefer to keep all, default, other-readable (and/or executable and in rare cases, writable) permissions as is typically found in the default settings for each OS. We are simply looking for best-practice, general reasons (they are often privacy-and-security based reasons, but now always) why we would specifically disable any world permissions.
EDIT 2019-10-23
We're investigating further on our own systems. We're running variants of the following command in system-file directories (namely /etc) on our various host systems (all Ubuntu) to further evaluate. (Suggests and guidance for this approach welcome.)
find . -name .git -prune -o ! -type l \( ! -perm /o=r -a ! -perm /o=w -a ! -perm /o=x \) -exec ls -ld {} \+
You the administrator are implementing policy that defines users that can access files.
A hopefully obvious example: user credentials must be protected, because if not auth is broken and the system is compromised. So, /etc/shadow must not be readable, or attackers can grab hashed passwords and crack them.
For less restricted files, disabling some of those permissions for other is different from removing all of them.
Usually, some random person who does not own the file should not be able to edit it. Unwanted changes can be introduced either by accident (viewing with editor and save with stray characters) or on purpose (grant admin to application that they should not have). This is why you will see umask 0002, aka o-w, on many systems.
Removing read is also a choice you can make. However, do this to files that don't actually contain privileged information, and you will get complaints of "restrictive umask". Asking someone to login to your web server and fix things will be much slower if they can't read the config file. If all users with logins are supporting the web server, why deny them review of the config?