It doesn't matter if it's Tomcat, Tomcat EE, or WebSphere.
J2EE webapp containers run webapps. No exceptions. Servlets belong to webapps. No exceptions.
The server.xml file is simply a configuration file that the catalina application program uses to configure a Tomcat server. It reads the file in and digests it using the Apache Digester, which then results in a customized Tomcat server. It's effectively doing the same thing that you are doing except that instead of hard-coded program logic, it's using a static definition.
The web.xml file is likewise digested as part of deploying a web application to produce the webapp's internal context definition objects. These days you can sometimes omit the actual file and one will be synthesized from defaults and annotations, but the structures are still there and still associated with a context path.
When you use the Tomcat addwebapp method, you are merely doing what the standard Tomcat deployer does when it constructs or digests a webapp Context. You define a context path and a codebase. The codebase is the location of the webapp's resources - servlets,
JSP sources, static files such as javascript, CSS, images, and so forth.
There is no "standard" or "default" webapp as such. There is a default servlet, but Tomcat automatically and invisibly adds it to every deployed webapp as shared code. The default servlet is what produces an index listing if you reference a directory resource instead of a file or servlet resource, it's what renders static resources as responses back to the client, and it's what constructs and sends the "404 not found page" if a resource cannot be found. It gets invoked whenever a resource path cannot be matched against the servlet path maps in web.xml.
I've never checked to see exactly what happens in Tomcat when you send a request to an Host where the context path doesn't match. It's possible that Tomcat may have constructed an internal webapp to generate the "404" page that comes back where the webapp has effectively only the default servlet in it, but even if it does,
you should NOT hack that to do things that any ordinary J2EE-compliant web application can do. Because what you'd produce would not only fail to comply with J2EE and JEE standards, it could very well cease to operate properly when Tomcat changes. The difference between being clever and being "clever" is knowing how to exploit internals but also knowing how to avoid having to do so.
If you are just looking for a system where you can package a Tomcat server and pre-defined webapp(s) as a ready-to-run unit, you might want to look at Spring Boot. It's designed for exactly that purpose.