One argument against producing a cross-platform framework is that it will always be targeted at the lowest common denominator - clients of the framework want to write code just once and it run 'everywhere' supported. So one awesome hardware platform would just look like any other platform that runs that framework as you can't leverage the platform-specific features.
Over time, this unfortunately results in frameworks leaning towards their most popular platform and hacking together support for the other platforms, or just lopping them off when the budget/popularity runs out.
One way to capitalise on the platform-specific abilities is to have something like a
#if PLATFORM_FEATURE_X construct around all the specific code or equivalent runtime checks which results in code bloat. This gets tedious pretty quickly, as variants of the same platform will need specific handling. For example, some XBox v1's had no hard drive, so games using cross-platform tools couldn't use it for caching, compared to a PC version that where you can guarantee a hard drive.
For Desktop/Productivity applications, platform look-and-feel seems to be important, but many applications have their own style so its' no problem to look the same on all platforms, e.g. apps built with AIR.
Hardware vendors like Apple, Sony, Nintendo and Toshiba will want to ensure that their products do something to differentiate themselves from the competition, e.g. Touch, Accelerometers/Gryoscopes, Blu-Ray, 3D display. It's unlikely there'll ever be a platform with all the features of all the competitors rolled into one (due to cost and complexity), so one will win out.