I noticed that with the exception of my Strawberry Perl reference, you didn't address a single point I made. Instead, you tell how friendly ActiveState has been (and I do agree on this point) and you then attack me. This is not productive. I listed very concrete issues and linked to the evidence.
Since AS can't support core module upgrades, users cannot use modules which require those (but see next paragraph). Since AS apparently doesn't fall back to Makefile.PL if the Build.PL has problems, users cannot use those modules. And when we have modules which have all tests pass but are still listed as failing, I, as a module author, have no way out.
Yes, I can tell users how to find other PPM repositories or tell them how to install a compiler and find nmake, but when I have thousands of dedicated servers, this becomes a support nightmare, drives up costs, and ensures that my company has to spend more more working around problems in a build process we don't control instead of providing more features for our customers. This costs our company money.
These are issues that ActiveState has known about for years. For a small company, they've done great things for the Perl community and I don't want to disparage that, but when one of the fundamental needs of a particular open-source product is not met, it becomes a stumbling block and toolchains must not fail if it can be avoided. The more difficult a toolchain is to work with, the more likely someone is to choose different tools. I've emailed ActiveState in the past about related problems and Adam Kennedy has communicated with them for over a year on this, to no avail. Even a quick search on Google has led me to a number of similar horror stories. I also know of at least one module author who no longer worries about Windows because of how painful things are. How this could possibly serve the needs of the Perl community, I don't know.