I think it's telling that the answer refers to "critical mass" rather than "functional parity". If I have a 3.x solution that requires ten specific functions, I don't actually need 4.x to reach "functional parity" with 3.x before migrating; rather, I need 4.x to get to the point where it includes those ten specific functions-- at that point, 4.x has achieved the "critical mass" required for my solution to migrate over.
Another reason I like the term critical mass better is that it's less tempting to interpret it as "equal to" or "the same as". What functional parity actually means is, "every thing A can do, B can also do" -- it does not mean that A and B look the same, or do things the same way. By way of analogy, both a barbecue grill and a toaster can make toast, but they look and work differently. What's more, they require different knowledge and skills. Now, if I already know how to make toast on a barbecue, why should I learn how to use a toaster? There are multiple reasons, including convenience, consistency, and performance. You can probably tell where I'm going with this... Yes, there will be a learning curve with switching from JSAPI 3.x to 4.x, but it's encouraging to know things will be better when we get to the other side of that curve. If we start climbing now at a reasonable pace, much of that curve will be in the rear-view mirror by the time JSAPI 4.x reaches critical mass in early 2018.
The answer focuses on the functionality available in each JSAPI version, but the "when will 4.x reach critical mass" question is an important (and confusing) consideration, too. Consider a scenario:
- Learn and use 3.x, knowing that sometime in 2018 you'll likely need to learn and migrate the solution to 4.x?
- Learn and use 4.x, hoping that the missing functionality will be added in time to meet project deadlines?
- Try to convince your boss to delay the start of the project until it's clear when the missing functionality will be added to 4.x (and begin learning 4.x in the meantime)?
The right answer, of course, is to use Web AppBuilder for ArcGIS to create the web mapping solution below budget and ahead of schedule, then take a two-week vacation at the beach (use those app strategies)!