I'm not sure if you have used Google Apps before, but from memory it has DNS and website verification, so I can only assume it'd be vulnerable to this sort of attack.

Let's face it, being able to serve content on a website at all is enough to prove you own it these days.

You are misunderstanding how DNS works. Just because I can get a google cloud name server to point example.com at my server does not mean I own the domain. The gcloud nameservers are not the authoritative nameservers for the zone unless the root .com registry points at them.

Google apps verification only asks the nameservers designated by the registrar for the domain.

This might be a large investment for the engine itself, but minimal investment for the game. In my experience, the largest, buggiest and most complicated parts of a game are all contained within the engine.

I believe the 20 percent improvement in perf and engagement alone justifies the effort. Otherwise, the choice of React in this instance is great because you can fail quickly (easy to learn + very easy to start integrating), therefore being able to stop blowouts before they arise.

The question is if those 20% weren't also equally attainable by improving the existing code instead of porting to a new stack.

What question? You seem to have already decided on the answer without asking anything.

Is it possible to achieve 20 percent improvement in perf and engagement by improving existing code instead of fully rewriting it in another technology stack?

What would be the monetary cost of such decision versus the monetary cost of the one taken?

Which approach would achieve the same value of 20 percent improvement in perf and engagement with lower amount of money being spent?

Did you read the article or just the word "React"? They're incrementally migrating, not fully rewriting the application.

Well the article is primarily about the technical implementation, not the business rationale. But they still mention the main reasons: engineer productivity, community support, and performance gains. All of those translate to money.

As someone who used to work on large Backbone apps I agree that it's a huge drain on developer productivity -- hard to add features, hard to test, lack of standards, etc. Not to mention the recruiting problem: I would never accept a job offer to work on a Backbone app again.