Looking at this from the library perspective I share @takluyver 's concerns that this will eventually become an expected feature and very much agree with @steve.dower 's point in PEP 690: Lazy Imports - #167 by steve.dower about how this needs to be messaged.
I do not think that the concerns of what can go wrong are being overblown (if anything everyone is giving them too little weight). In Matplotlib we have made the backend selection and import progressively lazier and at every step discovered a subtle way that a user was relying on a side-effect (I can track down the bug reports if anyone wants). I expect that this is change is going to produce a stream of really interesting bugs across the whole ecosystem 
(but given the amount of use that people are reporting from cinder, I would be very happy to be wrong!).
That said, I’m still enthusiastic about this proposal.
Matplotlib (and I think many of the scipy tools) have relatively long import times and want to reduce them. A major contributor to our startup time is that for both internal and external reasons we have a lot of re-importing between modules so if you pull one module, you end up pulling a majority of the library. Because these imports are done in public modules we can not drop the imports (or bury them in function calls) because we may have users accesses those name from the (re-imported) namespace. I have started to advocate that Matplotlib adopt SPEC-1 (or some other scheme based on module properties), but would much rather have this done at the language level.
I am only one data point, but I think the carrot for library maintainers is both that we do care about our users problems (or we would not be maintainers!) and that in many cases we are users of our own tools (e.g. at my $work we actually have tests that Matplotlib is not imported unless you pull in a very specific sub-module in our libraries) so we are also feeling this pain.
Another application of this that I have not seen discussed is that this makes making curated namespaces for a domain (that may pull from one or more libraries) much more practical. One of the criticism we get from people moving to Python from something like MATLAB or Mathematica is that the ecosystem is too scattered (you want feature X, go to library A, you want feature X’ you go to library B) and new users get lost. Being able to hand users a conglomerated and curated namespace across numpy, scipy, sckit-image, pandas, networkx, Matplotlib, … (that does not take forever to import) would be a pretty big step forward (leaving aside the process of how to sort out what should be in the namespace 
).
I see the practical reason for the ENV (you have some script that you can not fix that is invoking Python and you want the lazy), but I think it opens up too much action-at-distance. I am also swayed by the argument that by the time any Python is running, you in general have no idea what has or has not already been imported (thinking like a library developer not an application developer here) so it is too late to ask to be lazy. On the other hand, the CLI flag is localized to one process and you can be sure it is handled before any Python code gets a chance to run.