> The maintenance burden of the introduced deprecation should be pretty low.

This is going to cause an unpleasant amount of churn in the Tornado community. It's been idiomatic (going back 12 years now) to do all your setup in synchronous code before starting the event loop. I'm tempted to restore the implicit loop creation in Tornado's `IOLoop.current()` (which is now essentially a wrapper around `asyncio.get_event_loop()`).

> It leads to weird errors when get_event_loop() is called at import-time and asyncio.run() is used for asyncio code execution.

*Checks asyncio.run's implementation* Oh, I can see how that's a problem (and I've been giving people bad advice about the interchangeability of Tornado's IOLoop.run_sync and asyncio.run). But why does `asyncio.run` unconditionally create a new event loop instead of running on `asyncio.get_event_loop`? If asyncio.run used asyncio.get_event_loop it seems to me that we'd have the expected behavior and wouldn't have to make breaking changes to get_event_loop. 

> Low-level new_event_loop()/loop.run_until_complete() are still present to run async code if top-level run() is not suitable for any reason.

What if you're using run_forever instead of run_until_complete? (this is the common mode of operation for Tornado) There are solutions, of course (my preferred one is `await asyncio.Event().wait()`), but it's an extra conceptual hurdle to throw at users in a "hello world" example and this is why I've stuck with the model that uses (the equivalent of) run_forever instead of asyncio.run.