The reason it sucks has more to do with the language and the culture that has grown up around it, than the mechanics of building and deploying that this article talks about. These mechanics have to be solved for most languages. They're table stakes; mostly just a basic level of usability from which you can start to measure against other things.
If I had to name the single worst thing about Java, it would be the tendency for business code to degenerate into a 1:1:1 ratio of interface:class:public-method. For any significant piece of logic, it ends up living in a class on its own, with its dependencies injected either via constructor parameters or method parameters. Whether the constructor or method is used doesn't really matter, unless the method is to be called many times, in which case the constructor acts as a kind of partial application. And of course the class it lives in needs to be the only implementation of a corresponding interface, which only has a single method, the method in question. All other interesting methods this method calls must in turn be called via single-method interfaces, with these interfaces injected via parameters, one way or another.
The cause of this is a religion around a particular style of testing. The development driven by the need to create tests for everything leads to code that has very little cohesion, very little structure, and most closely resembles 80s procedural code, but with vastly more ceremony. Code is hard to browse and read because the link between method call and implementation is hidden in a runtime indirection via an interface reference. This lack of legibility in turn encourages doing more work in these methods (albeit broken out into private methods), and instead of an OO decomposition of the problem, you end up with a poorly factored procedural decomposition.
The biggest symptom is classes with names that are close anagrams of their primary method. For example: StaleJobsCleaner.cleanStaleJobs, StaleJobsFinder.findStaleJobs, JobDeleter.deleteJob, JobDepedencyFinder.findJobDependencies, etc.