I very much agree with this. My fear is that most users will get the impression that “enable lazy imports” is essentially a “go_faster=True” setting, and will enable them and have little or no ability to handle the (inevitable) problems. They will therefore push the issue back to library maintainers.
I’m lucky in that I don’t maintain any big libraries that have a programmatic API, but for the libraries I do maintain, I’ll almost certainly just refuse to support lazy imports (“if you hit an issue, reproduce it with lazy imports switched off, otherwise I will close it as unsupported”). Whether that’s a viable strategy for larger projects, though, I don’t know. And even if it is, the emotional work of repeatedly stating that position is far from negligible.
I’m all in favour of improving the startup time of Python applications, and in particular the cost of imports. But I think we should do so in a way that matches other tuning processes - provide a set of (ideally easy to use) tools that a motivated application developer can use to achieve better performance. But with full understanding of what they are doing, not by simply turning on a “magic switch” and expecting things to “just work”.