Except, most of those problems don't exist to the same extent with the Wii U that they do with PC development ...
First off, even open source physics engines are using cross platform GPU programming languages (OpenCL) to handle physics on the GPU. Here is a video of the bullet physics engine running on the GPU:
On top of that, the Open Dynamics Engine has OpenCL solvers and it could be argued that the "proof of concept" of running it on the GPU is completed; and it is likely that within a year a couple developers could have it ready for production environments.
Then there is the "steep and always changing learning curve" ... which is a problem because you have multiple hardware manufacturers with very different ways of doing things and the hardware is changing rapidly with how something is best handled on one generation of card being very different on the next generation of card. With static hardware like a game console you have 5+ years of stability to learn and improve what you're doing.
Now, to be clear, I wouldn't expect a physics simulation as large as the one in the video to be in many Wii U games; but even a simulation with 5% as many objects (1600 obects at the same time) is probably adequate for the vast majority of games out there.
I will be surprised if any third party game uses Bullet Physics and OpenCL in the future.
You'll find the vast majority of developers working on U titles using Havok because they get a free licence with every dev kit. Nintendo really have pulled out all the stops as far as encouraging Wii U development goes. Free Greenhill's MULTI IDE, Havok, Autodesk middleware and Unity 4 licences. That's tens of thousands of pounds worth of middleware for nowt. Indie devs in particular will be all over this, we'll see a shitload of ports of Windows Unity-driven games. Nintendo have also adjusted the cut they get from sales to the developers' favour too. The Wii U eShop could very well be the go-to place for indie developers.
