There's a couple of specific problems this was inspired by, but the more general motivation is your 4th point: currently all the Tomcat configuration is under /usr. This patch moves most of it to /etc so if you need to tweak it in an unanticipated way, your changes are honored by the package manager. Now for some specific use-cases:
BIGTOP-811. We can add /var/lib/bigtop/* to the classpath at build-time, but as the original intent was to detect the MySQL Java connector if it was installed by packages (in /usr/share/java) and the idea of detecting it and creating symlinks in /var/lib/bigtop was -1'd, this is the only other way I see to dynamically add it to the classpath. Because of Tomcat, Sqoop 1.99.x and Oozie won't be able to pick additional classpath entries from the environment.
BIGTOP-881. In order to enable HTTPS/SSL, users would have had to make several changes to the configuration under /usr. At the time the solution was to deploy two independent pre-built configurations and have the user choose the one they wanted Tomcat to use in the defaults file. With this patch, the configuration can be edited, there's only a single of configs, and that feature is very easy to turn on. I feel like SSL is a common enough feature that supporting the relevant config changes out of the box would be nice, but I'm not 100% married to the idea. At the very least we ought to move the configs to /etc and stop shipping 2 pre-built configs, though.
There are already more examples of this kind of thing in a certain distribution downstream of Bigtop, which leads me to believe these kinds of things will likely continue to come up. In very general terms, I think having Tomcat applications manage their configuration this way will allow Bigtop to continue making the experience easier without having to get one's hands dirty in the embedded Tomcat stuff.