I haven't used the standalone version, but I have used the boost version for build a cross platform RPC library quite intensively. Unfortunately compile times there were really bad, for about 10kLoC C++ I had a compile time of nearly 1 minute (about 5years ago on a medium speed machine back then). I later also built the same library using Qt and the compile times were below 20 seconds. I think the differences came from the fact that asio is heavily templated, you get all in headers and favors directly instantiated objects instead of pointers. In QT you mostly have pointers (and therefore work with forward declarations to the implementations).
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.
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.