Also, what does the overall Perl community gain from the TPF funding this project?

In short: diversity and choice.

I think the Perl community gains by opening up Perl usage on Windows to a wider audience. Until now, Perl on Win32 has really meant two choices: Cygwin or ActiveState, both of which bring a lot of baggage along with their benefits.

One of the downsides of relying on, for example, ActiveState, is that while they solve some problems for you, you wind up held hostage to choices that they make. One of the goals of CamelPack and VanillaPerl, etc. is to make having your own Perl distribution on Win32 as easy as it is on unix-based platforms -- with direct reliance on CPAN rather than intermediate repositories to allow for access to the most up to date modules available.

Here's a real-life example: Scalar::Util. ActiveState's PPM repository targets the first ActiveState release for a particular major version of Perl to maximize backwards compatibility and (presumably) minimize support costs. Because the version of Scalar::Util frozen into the first ActiveState Perl 8xx release didn't include the critical refaddr function, every CPAN module that requires a Scalar::Util with refaddr fails the automated build process for 8xx PPMS -- even though later releases of ActiveState Perl 8xx include more modern versions of Scalar::Util. That's a lot of modules -- including my own Class::InsideOut.

With VanillaPerl, I and other users don't have to rely upon PPM repositories -- they just use CPAN directly and can rely on the dependency management code already built into the CPAN toolchain. And, because a compiler is bundled (unlike with ActiveState), that includes XS modules.

I certainly don't think that's for everyone. Many end users may be perfectly happy with a PPM-dependent approach. But I think TPF and the community will benefit by creating more choices.