Before I begin, I would like to note that I created this thread in a way that does not violate the plugin's heavily-restrictive license, which can be accessed here. This thread does not explain how to compile the plugin, because doing so would result in a violation of the license. I am, however, detailing certain things that I found that I dislike. I used information that was provided by the official pages of the plugin (the GitHub and Spigot pages) for my research.
Source code will not be directly provided in this thread, however I will be occasionally linking to lines in the source code from the official GitHub.
The way AsyncWorldEdit works is confusing and broken in some cases
Contrary to what it sounds like, AsyncWorldEdit is not a fork of WorldEdit. It is a separate plugin that when installed, injects its own code into the original WorldEdit plugin by some weird Java hackery to make it behave asynchronously. As you can imagine, this breaks a lot of shit, and is most likely the reason it frequently misbehaves on the server.
Why the developer chose to do this, I'm not sure, but my theory (do not take this part as factual information) is that that he wanted to control how the plugin was distributed or even compiled through a license of his own. You see, WorldEdit is licensed with the GNU Public License, which among the many other things it requires for compliance, states that you cannot change the license of copies of the source code you make. Since doing what I theorized before to a fork of WorldEdit would violate the license, it's possible he chose the path of writing something from scratch that injects into the existing code to avoid violating the license.
The version on GitHub is not the same as the version in the GitHub releases
In the GitHub version the project's pom.xml files that Maven use (primarily to you know, compile the plugin) refers to dependencies that don't actually exist or are otherwise inaccessible to the public. This includes the code that makes the plugin work with 1.13+, making compilation effectively impossible. So, if an exploit is present in the plugin, we cannot fix the exploit ourselves as we do not have access to the source code to the version that we use.
The versions distributed through GitHub Releases do include these dependencies, however there is a catch. To deter someone from using a program to decompile the software, the developer scrambles the names of certain important class files in the distribution JARs that are provided in the GitHub releases. When the plugin starts up, it descrambles the file names of the classes and then loads them.
The code that descrambles and loads the classes is present in both versions, but the GitHub version lacks information that is required in order to descramble the class file names. This information is present in the distribution versions, but I cannot provide that information here.
The official GitHub pages, to the best of my knowledge, lack the information I've just noted here.
It is prone to painful log spam
AsyncWorldEdit's logging system is overly verbose, to the point where it can spam logs just from regular use. Many admins who have seen the shit it spews can attest to this. Sadly, there is no way to actually disable this functionality, which fucking sucks.
Conclusion
AsyncWorldEdit does work, but the way it works is painful and frequently breaks shit. In addition, it is impossible to modify the plugin yourself without information that is otherwise stuck behind a paywall (as the source code is actually incomplete), so if you want to maybe fucking disable the log spam caused by the plugin, you're shit out of luck.
If you want a version of WorldEdit that doesn't immediately crash the server when you make a giant sphere for your own private use, use FastAsyncWorldEdit. If you want WorldEdit to not crash the server immediately but also allow pretty much anyone to use it in an all-op setting and not have it crash from ridiculous galaxy brain mistakes like fucking loading schematics from the web, use AsyncWorldEdit.