It sounds like your problem is access to a C compiler, not authors using XS. That problem isn't the availability of a C compiler for your platform, however. It's a social problem outside of technology.

Perl is an open source community and code re-use is rampant and appropriate. I'd rather see a module use a widely used and well maintained C library than reimplement it and fall into disrepair. You mention openssl: when the C library that most people use has a new version, I don't have to wait for a Perl version to catch up. I don't have to watch parallel evolution in code that does (or should do) the same thing.

Every module is an extension of the Perl language, and they are all re-useable code libraries. The implementation details are the red herring here. Although it would be nice to have a way to select different implementations of things at a low level, and the programmer level I just want to use the same module name everywhere and know I'll get some implementation of it. If the local machine has the C implementation, I get the speedy C implementation. If it has the pure Perl implementation, I end up using that without changing my script.

This has never been a big deal for me because I just get the C compiler, and point out to clients the difference in paying more money and waiting longer for a pure Perl implementation versus downloading a compiler. You don't have to compile it on the target machine either, and with things like ActiveState's PPM, you don't have to compile it yourself a lot of the time.