Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
Personally I couldn't care less because both will be too much money for me to justify spending.
I also think there will be more variance since with DX12 game performance is more dependent on the quality of the developers.
On this point, devs have direct feedback as they code shaders themselves. they have a far better toolchain and debug chain for solving performance related problems with DX12. So while it will help using the ISV's for support. it is not as much of a requirement with Low abstraction API's.
Since take one case. dev tests game on one system and sees 30fps with code A. but 20 on second system.
He then alters code and the performance reverses.
with third alteration the performance balances but both gain lower performance overall. say arond 26-28fps.
dev could decide to write two code paths that suit the different architactures or carry on with trial and error.
for smaller devs we will more than likely see the middle ground approach while larger studios may check hardware ID's and seperate the code paths.
Good Developers already do this, and those with larger budgets will make different code paths if they see an issue. The problem is there are loads of bad developers out there, or they are constrained by resources so they don't always have to optimize the code.
IIRC TSMC 16nm actually results in a slightly larger core but also more power efficient when all else is equal resulting in about 2-3% net lead to 16nm for the same design.
(Does give potential for a mature 14nm to eventually take the lead).