See my previous answer here: PEP 810: Explicit lazy imports - #37 by pablogsal
But in short: we believe this global mode is important because there is a real and pressing need for it: large organizations are already forking Python or patching their own builds to enable global lazy imports (see the links in the discussion, the PEP and other material). Providing an official, supported mechanism means they can experiment and deploy without diverging from upstream CPython. We don’t want to make the global mode the main point of the PEP, but we do think it’s an important advanced feature: the fact that people are already forking Python to get it shows a strong need, and we believe providing it upstream is the right way to satisfy that need without splitting the community.
It’s intentionally marked and documented as an advanced feature, not something for day-to-day users or libraries. The default remains fully explicit: only lazy import (or __lazy_modules__) changes behavior. But for operators running huge fleets or codebases, having a single switch plus a filter mechanism is critical to get performance and memory improvements quickly, without waiting for every package to adopt the syntax.
So the “enabled” mode exists to serve that specific need. For most developers, nothing changes; for large deployments, they get a supported, standardized way to do what they are already doing today.