Update: 04 March 2020
My viewpoint slickly relaxed, though I still hold true that asynchronous programming is damn difficult to mentally implement.
What I originally neglected to identify is “why”. And I think the reason is simple:
People don’t intuitively think asynchronously.
Likewise, we don’t think in a caching manner.
And the core problem behind both is we have to simultaneously monitor and make decisions on actions that may or may not happen, at a time we can’t determine, and then proceed on a path [that would have been synchronous] to complete a task.
I tend to approach “asynchronous” programming as I do “caching”: that is, I prefer to touch neither.
While both are important for software performance, I also consider them “advanced techniques” and “optimisations” that, to be honest, I don’t think the average developer (including me) do all that well.
They require a non-traditional mindset, are difficult to learn, difficult to implement well (regardless of language or framework support), and as such, are easy to do poorly which increased the likelihood of errors and security holes.
I prefer to investigate more traditional synchronous and non-cache based approaches to solve problems before I go down these rabbit holes.