Let me start by saying I think the argument for binaries vs fat jars is overblown.

That said there is more complexity with the jvm. Do you have the right jvm installed? Where was it installed? Are there multiple versions of the jvm installed? Do you care? Can you mess with it? Have you accepted the license for the jvm? Should I use docker to manage all this complexity? Is the docker agent working? etc.

In environments where you are deploying to a single architecture that is more complex than "copy binary". In environments with LOTS of servers the (admittedly limited) complexity difference can add up.

IT says everyone uses version X.

This group IT, do they set up the servers? Do they make sure policy is enforced? Do they deploy your software? If so, they are doing the work and we should be asking them & not you whether they prefer JVM based solutions or single binary ones.

Most of the companies I worked for, only IT has a say what devs have on their machines and servers. You need tickets for everything.

First off, make the assumption that you're not just running Linux. Half your deploys are to Windows. If you don't do Windows then you'll certainly have fewer problems.

Second, Docker may be the solution. In concept it's great. But Docker isn't yet a first class citizen in Windows. For the time being it becomes yet one more run-time piece that has to be configured.

Clearly my map of the world not your map of the world (à la Korzybski). I find the various extraneous run time pieces constantly tedious and annoying. You don't. Can't say why you don't, but I'm to the point where I despise them. I don't want another call where I have to tell a customer they have to update this piece or download that piece or move this there in order to get the latest version of an application to work.

Docker and other containers are a response to runtimes failing to, ahem, contain themselves. It is true that you don't need a second solution if you already have one, but some people may not like the container solution.

I don't know about your situation, but at our end, to start JBoss after a new deployment, it takes about 75 to 90 seconds. While for production it may be okay-ish, it absolutely drives the developers and testers nuts.