As long as there's nothing stopping OEMs from adding a browser to their systems, and nothing stopping individuals from using a browser of their choice, I really don't see a problem. You want to install Chrome or Opera? Go right ahead.
I suspect you'll find that MS has been found to do exactly that. They've historically put pressure on OEMs by threatening to give them worse licensing deals than their competitors unless they complied with MS's wishes.
Your information about timeouts is correct. You can effectively create a cooperative multi-threading environment using such a technique. The purpose of doing this is NOT to improve performance. In fact, you take a slight hit for it. The purpose is to improve responsiveness. Locking the user's browser solid for 30 seconds straight is not going to make them happy. And when they get the "this script is taking too long" error message, they're going to kill the script and decide your app doesn't work.
If the app is cooperatively mutli-threaded, you can provide the user feedback on progress thus improving the perceived performance.
It seems that these are exactly the types of cases where a non-web application would be appropriate. In my experience, as soon as you get much beyond the wizard type data-driven apps that make sense in the browser, you end up having to reinvent all sorts of wheels that you get for free in a 'real' language. Implementing cooperative multithreading in a browser just throws up all kinds of red flags.
Neutrinos have bad breadth.
