I find the /etc/httpd/logs symlink more annoying. If you want to grep through your Apache configuration you have to explicitly grep through conf and conf.d otherwise just going to /etc/httpd and doing a grep -r you're searching through gigs of Apache logs.

grep -r shouldn't follow symlinks, -R does however:

      -d, --directories=ACTION  how to handle directories;
                            ACTION is 'read', 'recurse', or 'skip'
      -D, --devices=ACTION      how to handle devices, FIFOs and sockets;
                            ACTION is 'read' or 'skip'
      -r, --recursive           like --directories=recurse
      -R, --dereference-recursive  likewise, but follow all symlinks

requires someone to know there will be symlinks they don't want to follow, though :-)

As opposed to Debian, the distro which chooses to break tomcat (a program which unzips into a single folder and is thereby completely self-contained) up into a million different pieces and scatter them randomly all over your hard drive?

To be fair to Debian, that's how it's supposed to work. You untar into /opt, self contained, while your apt install puts things in the Filesystem Hierarchy Standard, which means config goes into /etc.

You'll find most distros follow some FHS standard, although there's some differences in interpretation.

Yes, it's a distro where you can find EVERY setting on /etc, even if the software creator decided you should know to look somewhere else.

(That said, making the package self contained is the most sensible way for the developer to release it. It's just not a good option for a distro package.)

Is there an aricle with specifics on this and why it was done?

I have no direct information about this specific case, but in ye olden Unix™ days, there was no /sbin, so all those binaries instead lived in /etc. The Red Hat symlinks could be a backwards-compatibility thing.

You mean bug-compability?

No, I would not mean that, since the previous behavior was not a bug.