Don't forget the "nearly every platform" comment from TFA. Apps aren't currently designed for use with a mouse, but it doesn't have to stay that way. The Android app format is coming close to being the fabled "universal binary", finally giving developers the long-promised write once, run anywhere ability.
Heh. The dream of the 90s is alive on Slashdot.
It wouldn't be the first. Java and HTML/JavaScript long beat Android to the punch. In fact, HTML/JavaScript does it better. OpenGL ES on Android isn't exactly platform neutral (my Mac doesn't have an ES driver for it's Nvidia/Intel hardware so the best it can do is software rendering, while WebGL is abstracted so it can render it perfectly.)
We can use the lessons from it's forebearers to tell why it won't be adopted in the marketplace as a universal app solution. Both Java and HTML/CSS make universal app deployment technically a reality. For the past 20-ish years I've been able to write a Java app and deploy it on any platform. HTML/CSS run well on both desktop mobile devices as well.
The usability problem that is always run into is that by pretending all platforms are the same, the usability strengths of each platform are ignored. A mouse and pointer is a really really basic example that both iOS and Android can handle, but what about security models? The Android security model, OS X security model, iOS security model, and Windows security models are entirely different. Apple platforms like to give capability access capability by capability, at the time they are accessed. Android doesn't work like that at all, it wants everything up front. So an Android app trying to access my Address Book doesn't at all have the API to do so on my Mac.
Or what about contextual menus? I expect those on a Mac but Android doesn't have them. Macs also draw differently. They expect scrollable content to slow under window sidebars and titlebars. Android doesn't expect that. You can't make an Android app act like it's running natively on a Mac without reflowing all the widgets in the window. And Android apps don't have multiple windows. I expect that on a Mac. Mac applications also have toolbars (as do Windows applications) but Android doesn't even have an API for that. All Mac applications have a re-arrangable toolbar, but Windows doesn't. Mac and Windows computers can have multiple GPUs, which means that Android would need an API to handle a window having to shuffle from one GPU context to another, and I don't think it has that... There are also font layout issues. Both Mac and Windows have different default fonts which could dramatically shift around line spacing, and what text fits where. Mac at least also has contextual definitions when you right click on a word. Will Android apps have that? My Mac apps support QuickLook in the Finder, but there isn't anything like QuickLook under Android to abstract into. I also like searching with Spotlight, but Android apps don't have any Spotlight vendors. Do Android apps ask for my user name and password to do secured operations? Again, Android apps don't have any idea of on demand security, and I really don't want to have to enter my admin username/password every time I launch an Android app. Same thing would apply to UAC.
If you hadn't stopped reading by now, you might be starting to get my point. The reason Java failed to take the desktop world by storm is that not all desktops are the same or even have the same capabilities. Yes, as you suggested, you can go down the road of adding a bunch of APIs to handle all these different scenarios. But then you're back to writing a bunch of code to support a bunch of different platforms. It's right back where you started. Java didn't end up saving time for multi-platform because the dream of writing once and running anywhere was unobtainable for desktop GUI applications, and it still is for the same reasons. It's technically possible, but the same user experience everywhere was unacceptable to users and unworkable. Even Microsoft wasn't crazy enough to believe they could get away with write once, run anywhere for Office. Office on the Mac runs/looks different than the PC version because when they tried to make the Mac version look like the Windows version Mac users revolted. I've had Windows Office users equally pitch a fit when they've been set up with the Mac version of Office.
HTML/JavaScript sidestepped this by defining very broad APIs and letting the platform make inferences as to how things should work. It was also shaped by the communal cooperation of all the different platform vendors to build something that could be molded to work on everything. Android's API does not leave much room for the native platform to reinterpret application logic at all, and it wasn't written by the platform vendors together.
It wouldn't surprise me if Google added this capability to Chrome. It would surprise me if there was any wide uptake.