I've learned that MySQL can compress communication between servers and clients.
Compression is used if both client and server support zlib compression, and the client requests compression.
(from MySQL Forge Wiki)
The most obvious pros and cons are
So, is compressed protocol something I should enable whenever I can afford servers with adequate specs? Are there other factors I should consider?
In my experience, most mysql servers are located on the same server as the webserver, so network bandwidth is not an issue.
I'd say that unless your db and app/web servers are geographically apart (ie not on the same server or network), there's going to be very little benefit in enabling compression.
From my experience it's especially useful if you're connecting to an external MySQL server that resides in completely another network (or even country). The benefit you get from enabling compression in such cases depends on the size of the data you're transferring, and the distance between the client and the server. As always, you should test your application with and without compression, and then make a decision which is most beneficial for your situation. There's no absolute answer for this question.
I don't see much point enabling compression if you query a MySQL server on same machine, or even on same network.
Performance benefits are going to be largely dependent on the size of the result sets that you are sending, in addition to the network bandwidth and latency between the database server and its clients.
The larger the result sets, the larger the latency, or the less bandwidth, the more likely you will see the benefit of compression.
Your maximum level of service is limited to the smallest bottleneck. So, you need to analyze where you're currently at regarding network and CPU resources.
The most optimized database server utilizes 100% of its CPU 100% of the time, otherwise you're wasting computing resources by having a processor that's sitting there not doing anything. Of course, you don't want it at 101%, so your target range is well below 100%. Yet, my point is that if you have a lot of headroom before you reach a CPU bottleneck, and the result sets are a significant size, and the network is a factor, then turn compression on. CPU cycles are cheap, especially unused ones (you do pay for electricity and cooling).
If you pay for bandwidth, trading CPU usage for bandwidth is easily justified, and even if you're not anywhere near reaching the bandwidth bottleneck, that faster speed, and higher level of service, is worth something.
Don't forget that the client must also expend CPU cycles to decompress the data. Not a major issue, but still a factor. In general, today's CPUs are faster than today's networks.