I understand that Java wants to remain conservative with its development roadmap, but the fact that the majority of an ecosystem uses a third-party framework is a good reason incorporate something similar into the language.
That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.
There are also often alternatives - e.g. Dagger for DI and MapStruct for mapping which go the code generation path which allow you to statically inspect the whole code path, you can also always trade the looser coupling for more directed paths e.g. for logging by avoiding the wrapper and using a logging library directly.
No they don't. Java is just not expressive enough, so library/framework authors have to decide between bloat or magic and they often choose magic for better or worse. There are languages that doing better in this regards.
Such as?
I'm not sure this is necessarily a culture, either. Java tends to be picked more for applications with more demanding/richer requirements, and so they need to do a lot. This demand for features drives a demand for richer frameworks. You see this exact thing happening with JS on the client. So to the extent this is a problem, perhaps it is a general software design problem.
No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary
That means not only reflection, but also most Dependency Injection (Spring autowiring, Guice...), anything that runs on annotations (including @Test and JAX-RS), any code auto-generation (e.g. Protobufs, Jooq), most mock libraries (e.g. Mockito) and most configurable logging, especially the logging libraries that try to auto-detect one another.
Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.