I think it runs the test suite live... It's not meant to be fast, but to demonstrate compatibility.

This app was written by a manager, don't read into it too much ;)

That's the paradigm of single-page apps (SPAs). Rather than the traditional client/server model where the server renders the page and sends it back to you, SPAs do all the rendering on the client-side, and simply pass data back and forth between the server using APIs. It's (in my opinion) a superior model for apps, but has a lot of disadvantage that make it unsuitable for websites—mainly that SPAs take longer to load initially and don't work without JS enabled (which also includes search engine crawlers).

Having said that, it's entirely possible (though not easy) to have your React app work without JS enabled by rendering it on the server before sending the page to the client. This way, you get the best of both worlds, but it's a lot of work to implement this properly for a remotely complex app. The answer in the short-term is that you shouldn't be using a "fancy framework" for anything for which the above disadvantages are a deal-breaker (like most public sites) until the server-rendering story matures and becomes more compelling.

Yay my tests pass. Wait, what were we building again?

They didn't break tests, instead a whole load of new tests were added, specifically around server side rendering, which exposed some gaps in coverage.

This is exactly the type of openness you want to see for such a widely used project like React

I mean, what did you expect?

Won't be long until someone upgrades their 16-thread 32GB machine because Facebook was "too slow"?

I type this on a dual core phone with 2GB of RAM that's faster than most desktops 15 years ago thinking I need a faster device.