Previously, mgw sent in a VERY nice patch to add support for libssh2. Unfortunately, I've hit some roadblocks in testing.
The pylibssh2 as available in the latest github has support for SSH agent, which is super important and NOT in the version provided via pip.
However, the libssh2-devel in CentOS (I'm using 6.2) does not have the necessary agent support, and results in compilation errors (LIBSSH2_AGENT undeclared) when trying to install libssh2. Obviously CentOS is a big cross section of the user base.
While I would like to offer this feature to those who want the performance/etc, I also know including it will make us suffer countless questions about how to get it to work, even if it's optional and on the side.
To me, it seems best that we support the default transport as paramiko for now, not proceed with libssh2, and look into having an optional (root level) message bus daemon for those that care about that sort of thing in the (medium, not near, not far) future.
I don't really want to peruse the challenge of getting EPEL/CentOS/RHEL/etc having a new enough libssh2, knowing how fun that process can be, and wanting to keep ansible mostly upstream friendly.
Those also wanting extreme scale out options also still have ansible-pull, which scales ansible using git+cron by inverting the workflow to be pull based. This is going to be superior to the message bus solution anyway since it doesn't require hosts to be up, and in a very large infrastructure, you can't guarantee the hosts are going to be up anyway. We can make various improvements in making that workflow easier to use/audit/etc.
So, TL/DR:
-- pylibssh2+CentOS = FAIL
-- ansible-pull already exists, FAST
-- nothing really wrong with paramiko anyway
-- message bus option on the table, but not an immediate priority
--Michael