A
web server is
not a
file server. Just because you see directories and files looking in via the filesystem doesn't mean that that's what
Tomcat serves up to web clients.
By default, if you dump a WAR file or exploded WAR directory (what you'd get if you unzipped a WAR) into the TOMCAT_HOME/webapps directory, Tomcat will construct a web application context, and thus define a webapp for each such WAR or directory. This only occurs in the webapps directory itself, and not in any sub-directories. The context path in the URLs for a given webapp would be the same as the WAR name. Furthermore, by default, if you drop in a WAR
file Tomcat will automatically explode it into a directory having the same name as the WAR, minus the '.war' extension, and use that as its URL context. One exception exists. For the root context ("/"), you cannot name a file "/.war" or a directory "/", so the directory name used for the "/" context will be ROOT.
To selectively block access to webapps or parts of webapps, you would have to secure the webapps themselves. That can be done by setting up access rules in the webapp web.xml files and defining a security context in a META-INF/context.xml file or an external context file.
To completely forbid
anyone from using a webapp, simply undeploy it. That is, delete the corresponding WARs from the Tomcat webapps directory.
There's nothing magic about the sample apps that came with Tomcat other than that they were pre-installed in the Tomcat distribution. You can delete them with impunity.
And listen to Ulf. Tomcat 8 is at or near production status. Tomcat 6 is still supported, I think, but will not be for long. If you have problems with Tomcat 5.5 or older, you're pretty much going to be stuck helping yourself - or paying someone - because most people no longer remember it and the Tomcat support team doesn't support it any more.
Software is not forever, nor is the price you pay only paid up front. Eventually, one way or another, you have to pay for ongoing support.