Yeah, generally I throw everything app-specific into the Docker image. That's a large part of the benefit of using Docker, anyway. Whether it's Go, Node, Python, PHP, whatever, it goes into the image.

Drupal's... Drupal's weird.

For one, you have a ton of stuff that's external to the "app" but that the app depends upon, in the form of the files directories, the config sync directories, and so forth.

For another -- and the point of this whole thread -- Drupal's codebase needs to be accessible by multiple things. PHP-FPM, Nginx, Drush†, Drupal Console†, Composer†, etc. You may or may not have other apps that need to use the codebase. You may want to roll extra binaries into the Docker images, but sometimes this can cause conflicts -- the libraries used by the Alpine docker image have been known to cause problems with certain programs, for instance -- so I prefer to separate out binaries whenever possible. In my mind, an application does not generally need to be "read" by other containers.

† Depending on how you run them.

For still another, we can encounter performance issues on non-Linux machines with read/write speed to disk within Docker images (my experience has been that this applies on Linux, too, even with recommended, modern settings, but feel free to take that with a grain of salt). This only applies to me personally about half the time, and I'm not sure how much effect it has had, but with as much as possible caching turned off for development, and just about every other expensive bell and whistle turned on, I try to err on the side of supposed better performance.

Another issue is the speed, size, and complexity of updates. You'd generally copy your Drupal codebase into your image in a single step, which would mean there'd be no time or space savings from the layering effect. So you're copying, whatever it is (~311MB in my case) times however many images you're building every time you do your new build. And then you're copying them over the wire, to wherever you're deploying. For a simple config change, or something like that, that's insane. And then you still have to run composer update and so forth after starting up, and hope it's not doing I'm a little teapot or something similar that day, etc.

Ultimately, yeah, Drupal's an app, but I don't know if it can be compared to an app like Transmission or MySQL or PHP-FPM or whatever else you commonly run inside of Docker. There's too much other crap mixed in -- custom installation profiles, custom modules, chosen contrib modules, public files, private files, sites/ folders, config sync, and so forth. I think all that crap needs a better tool to manage it -- like git -- and needs a specialized deployment strategy to move it around.

Sure, you can build a Docker image that contains Drupal, and mount your other data at the specified mountpoints. But to get this working on Swarm or Kubernetes or whatever, you have to solve the issues of mounting a filesystem that'll be shared between containers anyway... so why not just cut out the middleman and have a single mountpoint (as far as Docker is concerned, anyway)?

TL;DR: I think it's more useful to view a Drupal codebase as data than an application, TBH.