"DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability."
You don't need a DI framework to do any of what you described. Also, I believe that what you are saying doesn't fundamentally describe DI, though it is related. In this post I go over what DI really means: https://sreque.blogspot.com/2019/09/dependency-injection-101...
I have never seen a case where using autowiring forms a legitimate tradeoff; it has always resulted in worse, harder-to-maintain code with little benefit in return.
I conflate Spring with Spring Boot because Spring Boot is built on Spring and most of my problems with Spring Boot apply equally to Spring.
DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability.
Autowiring mechanisms where you have some kind of global bag of (pseudo-singleton) services by type, and wire service dependencies implicitly by type rather than explicitly, are a legitimate tradeoff that's appropriate for some cases.
Don't conflate Spring with Spring Boot. One is a framework that offers some legitimate value even if it makes some questionable tradeoffs; the other is a fractal of bad design.