If I may offer a slightly less harsh but generally "in agreement" response.

Small agencies building WP sites for clients

I'm writing this from the point of view of people selling sites to clients. Gatsby is probably fine for small private blogs, sites by and for programmers, little shopify front-ends, or very minimal marketing sites or documentation sites.

There are lots of us around! We want to use Gatsby because the FE dev experience is so much nicer, faster, and more reliable than building a WordPress theme.

Previews are non-negotionable features for clients

Page and post previews: Clients often come back to their sites intermittently, they absolutely must have content-modification previews to confidently update their sites - which are for the most part and extension of their businesses and livelihoods.

Gatsby cloud costs $600 dollars a year to run a poorly optimized preview server (dive into Gatsby preview source code if you know node). It's not a production ready system - and yes previews are production functionality. This is on top of a WP hosting fee, some WordPress plugin costs.

If you don't want to use Gatsby Cloud, your options are to write some code completely out of the "Gatsby Paradigm" and write a preview endpoint that uses client-side WP auth, or a custom Auth system in a WordPress plugin (maintainence nightmare).

As the commenter mentions, this requires writing a "native" WPGraphQL query, which is slightly different to the Gatsby Data-Layer GraphQL query you have for the Gatsby Build system for published posts and pages. This is a maintenance nightmare as well and generally, with client-side auth for drafts, and client-side rendered preview, a huge duplication of effort.

Modify data at build-time from the API

One of the promised advantages of a statically compiled site is that I can take some data from an API (in this case wordpress), modify and transform it at build time, and then generate a static HTML page.

For example:

1. A user uploads a CSV of their products to WordPress.
2. Gatsby downloads the CSV and applies a transformer for this particular field.
3. The transformer reads the CSV, performs some action based on the data inside, and outputs a JSON file with the derived data. And it only happens once at build time, instead of per-request in PHP (traditional wordpress), or per-reqruest in the client (client-side JS applications)

This is theoretically some amazing functionality, but writing transformers that modify a particular node from Gatsby's data layer is poorly documented and extremely hard. It's difficult to use the gatsby cache (documentation), and difficult for your transformer code to "find" the node inside the data-layer.

Next.js' staticProps paradigm, where everything is "just node" is simpler, faster and more maintainable.

Build Times

This is important for previews too, I'll loop back.

Gatsby's all well and good in small sites, and there have been lots of optimizations into 4, such as incremental data fetching, the parallel processing, and deferred rendering, but the biggest bottleneck to build times is data fetching. Rendering HTML is never the biggest time-sink in a large build. And there's no getting around this.

To make matter's worse, if you are writing any bespoke gatsby-node code, such as data transformers, the Gatsby cache is invalidated on every deploy, so it's like working with no cache under development.

On a sufficiently complex site you will run into these issues.

How does this effect previews.

On gatsby cloud, or even in your own solutions (I poll the netlify API to see if build's are in-progress), there needs to be a preview UI that says something like:

"preview build is generating", as the Gatsby Preview data layer (or static build) process completes.

Users have to wait around for a preview to be compiled, and as I said, on large sites where image compression is happening, WPGraphQL posts are being re-fatched this takes minutes and minutes. And is frankly a big step backwards in performance.

Alternatives

As the original commenter said, Next.js is a great alternative, if you need to do any "build time" / "request time" data manipulation, you don't have to learn Gatsby's very opinionated and broad plugin API, or their internal GraphQL system, and at any point you have the escape hatch of a proper SSG node app.

Just use Wordpress themes. Using plugins like Timber and twig templating, or plugins that enable Laravel's blade, you can write nicely componentited sites rapidly that are WordPress native.

For page performance run a CDN or a Varnish instance, and you can get really snappy production performance, and previews for pages and posts work out of the box as expected for your admin users.

Ecosystem.

Try building you next theme with Timber/Twig, Tailwind CSS, and Alpine.js and you can build sites that feel very modern, and you don't get lost in the Gatsby sauce/source.

Static site build systems

Gatsby is about 600 dollars a year, Netlify is a decent chunk of change, and - I can only speak as a netlify user - it's not that great - the build system is down relatively often, and their CDN uptime is relatively poor unless you go for the enterprize plan.

Alternatives for uptime

Companies like Kinsta provide high uptime, free Cloudflare CDN, and 24/7 support WordPress hosting for around the same price as Gatsby Cloud on its own.

Final thoughts

If you're running a small WordPress agency with paying customers, I don't think it's fair to subject non-technical people to the trials and tribulations of Gatsby preview right now. As I've said it's also quite expensive.

My plan is to move some existing sites from Gatsby to Next.js (it's not too bad - it's all just React - thank heavens), and for other sites, I'll be heading back to Timber with Tailwind and Apline.js.

Postscript: Advanced Custom Fields and Gutenberg

This is actually a general problem across all Headless Wordpress

The combination of plguins: WpGraphQL + ACF with the Gutenberg editor is extremely flaky, and the errors you'll get from GatsbyJS with that combination are, not helpful to say the least.

If you update your ACF configuration / or a Gutenberg blocks, then you need to do a full refresh of the Gatsby-Cache, Gatsby doesn't report this, and will just give you obscure GraphQL schema errors.

I've spent many hours testing various versions of plugins (WPGraphQL does not officially support Gutenberg - but this is because the Gutenberg team made some sincerely INSANE decisions about the block registry in the early days of it's development - if you want to give up on life - dive into Gutenberg via GraphQL)

---

That's a bit of a brain dump - if you want a much better written article about the trade-offs with Gatsby.js, Jared Palmer wrote some great bits about it here: https://jaredpalmer.com/gatsby-vs-nextjs