I wonder if it's because there is such a sharp line between what a Java programmer can do in Java, and what the JVM does to make that possible. Much of what the JVM does is impossible to even describe in normal Java. That line doesn't exist in, say, C++, where the compiler is just another C++ program.
With the caveat that there are JVMs written in Java, so that line can be crossed:
The same mechanism could apply at the Spring Boot boundary. Using Spring Boot (for simple applications) is easy enough. Implementing it takes code that is beyond bizarre.
The JVM is not magic, neither are Java programmers magicians, but I think the reason magical terms are used to describe Java systems is that the ecosystem had lots and lots of time to develop libraries and abstractions (a few of which happen to be of the right kind, read: leak just the right amount). Your typical Java programmer is well aware what it takes to implement a battle-proof connection pool, and will not attempt to implement their own. To them, adding the config stanza to enable a connection pool indeed feels like magic. Other platforms, that come with preconfigured connection pools, do not leak this to the programmer, and 80% of their users will not know what a connection pool is.
The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms.
The ability to swap out basically any component of a framework like Spring simply by including a different dependency or replacing a bean at runtime allows for fine grained tuning that isn't possible in many other frameworks.
But this flexibility and/or modularity is enabled by a heap of pretty magical abstractions that glues everything together.
The Java library developer's aesthetic has traditionally been to make things possible, rather than to make things easy. So you may have to write a lot of code or config to get something to happen, but you will have a lot of control over what happens.
This is the opposite emphasis to, say, the Ruby community, which values a simple, lickable, surface interface with a large amount of opaque magic hiding behind it.
With the caveat that there are JVMs written in Java, so that line can be crossed:
https://www.jikesrvm.org/
The same mechanism could apply at the Spring Boot boundary. Using Spring Boot (for simple applications) is easy enough. Implementing it takes code that is beyond bizarre.