Well, I feel sorry for all those who paid for support from W3TC and didn't get it; hopefully you will get some form of reasonable compensation.

To all others who, like me, have been using this fantastic caching plugin for years without much hassle (except for learning how to configure it), well, shame on you if you don't do anything else but complain; Townes is not under any obligation to continue to support freeloaders. Also, you got the code; put it on GitHub; continue to develop it, if you wish. After all, you get 100.000 or so lines of code for free. There is little else that you need to do (except the occasional bug fixing; dealing with the occasional exploit or security issue; and fighting obsolescence, as new versions of PHP and WordPress come out regularly scheduled, deprecating lots of functions and changing the way things are programmed).

More seriously... I believe that Scott Hartley above has hit the nail. W3TC is not for everybody. I have been telling that to pretty much everybody I know — both 'in the flesh' but also in many forums and blogs and whatnot. W3TC is way cool in the way it deals with object and database caching (and yes, so far, there is nothing else doing the same; I have seen some 'widget caching' plugins which allegedly attempt to do what Townes has done, but at a very small scale and with little success). But you may not really need all those bells and whistles. After all, from the many comments that I've read here, with people successfully migrating to page-level caching services (either free or paid for), well, that's more than proof that none of those websites really, really needed all the extras that W3TC provides. For reasonably static content, after all, any simple page-level caching service is more than enough. Even just activating CloudFlare in front of your server and using Jetpack's Photon is more than enough — why worry, if you have less than a request per second on your website?

It's when you start getting hundreds or thousands or more requests per second, and when most of those requests require juggling with logged-in users and their cookies and tailored JS to handle them — as is the case on the high-end e-Commerce platforms, for example; or a popular BuddyPress installation — then, yes, your puny little page-level caching service will simply die. Because all requests will now be hitting your PHP engine and the database. All of them. Thousands of times per second — or possibly more, because WP (and WP plugins) is keen on doing quite a lot of table joins. Joy.

It's at that time that you will be most glad to have an enterprise-class caching module: one that works in those critical conditions. One that is able to isolate the complexity of the WordPress engine and the way each element on a page connects to the database for making requests — when there is no 'simple' way to cache a page. That's where the beauty of W3TC comes into play.

But for those blogs or websites with 50, 500, even 5000 visitors a day? Forget it. Even if you host quite a lot of websites on the same server — each with low traffic — there will not be a huge performance increase due to W3TC, compared to 'simple' page-level caches (such as WP Super Cache, WP Rocket, or WordFence's own Falcon Engine). W3TC, after all, will be dealing mostly with page caching anyway — perhaps saving the odd database access here or there, but it won't have a huge edge over other, simpler solutions.

Consider my own case. After months of struggling to fit all the small websites I host inside the available memory — and utterly failing! — I decided to push all of them to a server with twice the CPUs and four times the RAM. Needless to say, even when unoptimized, the server works like a charm. It neatly purrs with joy at the largesse I have bestowed upon it. Basically, it's sleeping most of the time — and serving perhaps four or even ten times more requests than before, in a fraction of the time (in some cases... it's 20-30x faster).

I did some benchmarking. I started from a 'standard' WordPress install, with no cache whatsoever. Then I started adding things to it: first, CloudFlare; then a simple page-level cache (I used Falcon Engine, just to save the trouble of installing one extra caching plugin). Then I started tweaking with nginx's fastcgi_cache, placing everything in memory. By then, few requests ever came to WP itself, but I could do better: get nginx serving the static pages directly, not even hitting the PHP engine. Cool: performance, in terms of page load speed, improved tenfold. So I went on, installing W3TC, and tweaking the configuration so that nginx was serving static content directly from memory — basically, W3TC's page cache was not even being hit. I still needed W3TC to write static pages on cache, of course, so that nginx could serve them. This wasn't easy to achieve, and, in some cases, I was not even sure (in spite of all those extra headers) where the actual page was being served from... memory? disk? CloudFlare? Or from WP itself? Sometimes it was not 100% obvious...

Was there any major improvement? Of course not. From a statistical viewpoint (both the testing server and the server being tested were 'on the Internet', although the testing server has practically zero traffic), it was impossible to see a difference in performance between the easy, page-level caching solution, and using W3TC together with a super-tuned nginx/fastcgi_cache/php_fpm solution. On top of that, I started using PHP 7, which includes the nice JIT (yay, 15% speed improvement, just by installing it) — but that didn't make a huge difference, either, except, of course, that W3TC seems to have many compatibility issues with PHP 7. By the time I'm writing this, who knows, version 1.0 of W3TC might be out, and fix all those issue, but, at this very moment in time, I basically have the choice to keep PHP 7 — which works with everything I've got installed on all my websites except W3TC and New Relic — or to go back to PHP5, because, as far as I can see, W3TC isn't even writing pages to disk at all. Or if it is, it's hiding them well — so well, in fact, that I don't know where to point nginx to them :) thus pretty much making the exercise pointless...

In any case, my long story should just be an example to those who are blaming Townes and grumbling about the lack of fixes and updates and upgrades... be honest with yourselves, and eventually with your customers. Do you really need everything that W3TC offers you? Because if you do, you know how to configure it to make sure you're getting the performance you need out of W3TC. If you're scared by the W3TC configuration panel and find it 'too difficult to use', then it's highly likely that neither you nor your client/customer really, really need anything else but a simple page-level caching plugin and a well-configured server to run it. That's all you need.

On the flip side of the coin, I can see even here on the comments that there are certainly a few people who do need W3TC for their customers, and they have nothing else but praise for Townes and his excellent work so far. And there are a few curious people like me: willing to learn how to do something new and understand how it works, even if we don't really, really need all the performance and features of W3TC. But it's just good old plain fun to learn new things. I still have a few options in W3TC that I haven't toyed with; and I have only signed up to New Relic today, just to find that it's not compatible with PHP 7! Bummer. It's not easy to live on the edge... without getting cut.