I'll take a shot in the dark and say they probably value their compile times. Every boost library I've ever used has the tendency to pull in the world from a single header and take forever to compile.
If I should make a guess then I'd say that the original author of that part of the library either started before ASIO was standalone and/or simply has a hatred for boost (which would be unwarranted), or he/she was simply more experienced with libevent...
IMHO it's quite sad that they didn't use ASIO though as it's far more extensive.
I've worked on projects where touching a main header incurred a 1 hour compile even with Incredibuild. You can understand how people can get sensitive with compile times in cases like that.
Other question: how would wangle compare to Cap'n Proto (as the post mentions that wangle is an RPC framework, and is zero-copy)
Besides that I think asio is a really good library. It gives you LOTS of options how to handle your workload. E.g. much more than libuv, in the sense that you can mix asynchronous and [non-blocking] synchronous IO calls inside your application, do IO calls from different threads, organize work with executors (io_services) and strands, etc. The drawback is that not all of these patters work good, and giving the users this kitchen sink of functionality could lead to worse results than a more focused approach. E.g. it took me a while to realize that calling io_service.run() from multiple threads is not the best idea.
The other commenters are probably right that they wanted to integrate with folly's existing async infrastructure.