I think this misses an important point, and it’s a smaller version of the same oversight that made the Python 2 → 3 transition so painful: library authors. All those of us who write code to be imported and run by other people, and therefore don’t get to control the environment in which it’s running.
Realistically, we won’t get to tell everyone that if they want to use our library they can’t use this new lazy import thing that Python just added. Especially as it’s meant to make startup faster, and performance tricks always get cargo-culted to people who don’t want to think about what they mean (one weird trick to make your Python scripts start 70% faster!). Within a year or so of releasing a version of Python with this option, we’ll probably have to ensure our libraries and examples work with and without it. I’m sure we’d manage, but please remember that opt-in features for application developers aren’t really optional for library developers.
Features like __init_subclass__ make it really easy for code to have non-obvious side-effects, like a parent class keeping track of subclasses that have been defined. And ‘import this module to add something in it to a registry’ is a moderately familiar pattern, e.g. hdf5plugin is an example that springs to my mind.
I know this is already in the ‘rejected ideas’ section, but I’d much rather see something like this be opt-in at a module level - some way of declaring that a module has no import-time side effects (or perhaps none that matter) and so it’s safe to lazily load it, and maybe also load it in parallel with other stuff. The main argument against that is that application developers can’t get a big speed up straight away - but I think there would still be a significant impact in the longer term as modules opted in to this.