For now!
If you live in Europe but work for a US company that requires you to work US times, it's simple, you work US times. This is how I've worked before and it's worked out perfectly. In fact, I'm a bit of a night owl so I much preferred it.
I live in Europe and work for a very remote-friendly, NY-based company, and I work pretty normal European hours. I have 2-3 hours of overlap with the various members of my team, and that's all I need. (In fact, I'm more productive in the morning here because it's easier for me to focus when our group chat is mostly quiet.)
Of course, it's not as simple as saying that you can work from anywhere for anybody at any time, but I don't think it's fair to say that timezone issues are not for the company to solve.
Your not, what AP thinks is reasonable would be considered rediculous if you frame it under normal satellite office scenarios. Can you imagine Sydney Googlers all catching the late train into the city to work the night shift. Like come on.
Re stripe limiting to NA only I get their concerns but its a failing approach. They're going to build out remote teams and a bunch of practices that rely on this timezone sync.
Swapping out real-time communication to async communication is going to be much, much harder once those practices are ingrained.
They also need to add more than just engineering into this remote hub. Having all your non engineers in offices is going to create a very odd adversarial culture.
To solve the timezone issue, you put in place as much tools and processes as possible around working asynchronously instead of having meetings all days. This is why most remote setups work better in fully remote companies - they are more incentivised to put those things in place.
But a lot of companies take on "Core hours" and essentially solve the timezone problem even with a physical office. With core hours management is deciding that they don't want to solve the "timezone issues".
I wonder how well the opposite end of the spectrum would work. Our async communication tools are pretty good these days. You could keep someone solving the problem all day long with just 3 or 4 hires but instead people choose to work on the problem in scheduled bursts of 6 hours with their entire team.
If you have timezone issues at all (outside of your on-call rotation), that means you haven't figured out your remote story yet. Which is totally fine! I'd have trouble imagining how you figure it out without already doing it. So it makes sense that they're starting in a half-remote state and then intending to get really remote at some point.