Since I work a lot in embedded loops where long running blocking snippets could literally break your I/O, lead to visible/audible dropouts etc. this would be the obvious answer.
All async does is give you (some of) the tools to make code non-blocking.
This could potentially be avoided by clever enough compilers or runtimes, but I am not sure whether that would really be benefitial.
I am a fan of making things explicit, so the closer peoples idea of what aync is and what it isn't matches reality the better. Alternatively we should get the definition of what async should be clear first and then make the adjustment to the abstractions so they give us the guarantees people would natuarally assume come with that.
There used to be a few compilers that used static analysis to predict the cost of a call (where the cost of I/O was effectively considered infinite) and in which you could enforce that a branch only had a budget of N. Modern architectures tend to mess up with any finite value of N, but you could fairly easily adapt such techniques to detect unbounded values.
There's a style of "asynchronous programming" where everything is designed to be non-blocking and there can be asynchronous programming with blocking code. In fact the first style can be emulated by offloading every blocking call to a different thread/greenthread/fiber and that's basically what's happening under the hood unless there is some fundamental support for non-blocking at the lower levels (sometimes all the way down to the hardware).
If you look on the bright side, it looks like free-threading is approaching, and OCaml has demonstrated how, by removing the GIL and adding exactly one primitive, you can turn a powerful enough language into a concurrency/parallelism powerhouse with minimal user-visible changes!