You would use the opt-out mechanisms already described in the PEP to say “all imports in module W should continue to be eager.” You can do this as the application developer without touching the code of module W. This is a very important component of the PEP.
Unfortunately I don’t think this is a practical description of many real-world scenarios where PEP 690 can result in huge performance improvements. Often it is not some particular library that is noticeably slow to import, it is simply the sum total of many perfectly ordinary modules that add up to “slow startup” because they are all eagerly imported every time, even though only ~30% of them are needed for a given invocation of the program. How do you propose that the author of a CLI in that scenario would achieve improved startup times via lazy imports that have to be manually enabled at each import site?
If the PEP cannot help in that scenario (which I think is the most common relevant scenario), then IMO it is not really worth it.
Also: importlib.LazyLoader already exists and is enabled all-or-nothing, globally. The Python ecosystem doesn’t seem to have been overwhelmed by people trying it “just to see if it makes things faster.”