I recently had a similar issue, a MWE can be found here (and also attached):
https://gist.github.com/N-Coder/89b1be8e5cfb83b1b03ade8485676982
As soon as `loop.stop` in loop_stop_problem.py:44 is called in a non-threadsafe way from another thread, i.e. without loop.call_soon_threadsafe, the loop seems to hang in `self._epoll.poll(timeout, max_ev)`.
This can be seen when comparing the two outputs in threadunsafe_loop_stop.log (without loop.call_soon_threadsafe) and call_soon_threadsafe_loop_stop.log (with loop.call_soon_threadsafe). Please note the time difference after "Waiting for loop join".
The loop seems to hang until the (seemingly random) epoll timeout occurs, or the next pending events needs to be processed (which might take quite some time).

There is also no explicit note about this behavior in the doc of the function (https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.stop), only a small note in the doc of AbstractEventLoop, informing you about the non-thread-safety of the whole class.
Also, other methods like `call_at` use `BaseEventLoop._check_thread` (https://github.com/python/cpython/blob/3.6/Lib/asyncio/base_events.py#L549) to check for violations when running in debug mode. Unfortunately, `stop` doesn't make those checks.
All this together makes this bug very hard to find.

So, i'd vote for adding a short `if self._debug: self._check_thread()` to the `stop` method.