Most of the applications I've seen has a war file baked in the docker image where the application server (tomcat) lies. I recently encountered an application war mounted as a volume to the tomcat container. When to use this kind of approach? The only case I can see is when you lack docker registry space and you have a lot for volumes (PV). I am converting dockerized and non-docker app to kubernetes deployments
Especially on Kubernetes, always put your application code in an image and never put it in a volume.
The core concept of a Docker image is that it's a self-contained application and its runtime. If you have the image, you can just run it without having any other parts. You should not need a separate copy of the application on the host or in a volume to be able to run the image.
In Kubernetes in particular, there's the additional challenge that there are almost always multiple nodes. If your code is "baked in" to an image, if your pod spec references an image, the node can just pull the image and it's done. You can also easily upgrade your application by changing a deployment's image: tag (or, if something goes wrong, downgrade it the same way).
Volumes present a couple of challenges that make them inappropriate here. The volume types that are straightforward to get can't be mounted on multiple nodes concurrently. You'd need to manually copy the application code in (it's hard to get direct access to volumes on Kubernetes), restart everything manually, and hope old pods don't read new files and get confused.
This does mean an image registry is effectively required to use Kubernetes. (Most public cloud providers have a hosted registry service and that's usually a reasonable choice.)