doubles the cost of implementing anything. Say a customer wants feature-X. Unless you're magically at the point where in your 2-3 year cycle where you're switching, both the A and B team need to implement feature. Of course, that's assuming you don't just tell the customer to stuff it and wait 2-3 years.
You're also assuming that you know ahead of time all use cases and interfaces. It's surprising how dependencies are taken. I've seen large scale systems break when a HTTP 204 was changed to a HTTP 206, or a base36 field changed to base62. Now again maybe you're thinking the consumer can stuff it and update everything whenever you decide to switch over, or that you'll have captured everything and have tests around it. But.. for any sufficiently complex system with a sufficiently large customer base everything about your interface becomes your customer contract. Changing everything all at once is going to break a ton of things nobody ever thought about.
Doing upgrades every 2-3 years means you're pretty much never going to be good at them. Institutional knowledge seems to have a 2-3 year memory horizon. Sure, you get that one person who is a bit of an archeologist/historian but tenure at most shops is not long ("The median number of years wage and salaried employees stayed with their current employer in 2018 was 4.2 years" - first hit on Google). While you're upgrading every 3 years, each team only does so every 6 years. Nobody is gonna remember what it looked like.
There's also a meta point, which is what are you actually trying to solve? Is it so hard to go from architecture A.v0 -> A.v1 -> architecture B that you need to build A, maintain A and simultaneously build B? If moving between architectures is so hard but moving between versions of an architecture isn't - why is that the case and why can't you make the former case easier?
I'm assuming that your plan has you upgrading the A-architecture within those 2-3 years. Maybe you're saying you wouldn't touch it at all and just hope there are no security issues or features or scaling you need to do.
There's also another point which is you've coupled all changes to a particular cadence. Maybe you want to upgrade your network, servers, storage systems, OS, application services, etc on different cycles. At the very least you're sorta hoping that all of those things have similar release cycles, which realistically you're going to be picking some network switch that's been out for 2 years and marrying it to a storage product that was released last month (because the previous one is 5 years old and will be out of support before your next refresh).
And scaling... what happens when you can't get the same server you were ordering 2 years ago? Tell users they can't have nice things until the other team rolls out their massive platform shift in a year? Or would you adopt a new platform to scale on, in which case, why are you doing this A and B team thing again?
And not only do you need two teams, but you need two sets of hardware which means you need twice as much datacenter space, etc etc. Do folks need to two desk phones when you roll that out?
And ... I'm gonna stop here...