Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.
There's some truth to this too honestly. At $JOB we prototyped one of our projects in Rust to evaluate the language for use, and only started using Docker once we chose to move to .NET, since the Rust deployment story was so seamless.
Haven't deployed production Java in years, so I won't speak to it. However, even with Go's static binaries, I'd like to leverage the same build and deploy process as other stacks. With Docker a Go service is no different than a Python service. With Docker, I use the same build tool, instrument health checks similarly, etc.
Standardization is major. Every major cloud has one (and often several) container orchestration services, so standardization naturally leads to portability. No lock-in. From my local to the cloud.
Even when running things in their own box, I likely want to isolate things from one another.
For example, different Python apps using different Python versions. venvs are nice but incomplete; you may end up using libraries with system dependencies.
