Earlier quoted context omitted.
"Is it time to just write an X86 API on top of GPUs and get rid of CPUs?" How many days are you willing to wait for your computer to boot? GPUs aren't "better" that CPUs, they're different . Between the two, CPUs probably make better GPUs than GPUs make CPUs, but it's a tough call; neither of them are very good at the other!
We've been building personal computers around GPUs for a long time now. The CPU based computer was kind of an oddball IBM "thing". Old MOS (nintendo, commodore) and ARM for example seem to have the CPU serve the GPU in most configurations I've seen.
Huge, huge swathes of your normal boot process would be trying to run on a single GPU execution unit, since there would be no parallellization available, and your GPU is terrible at out-of-order dispatch (i.e., basically can't do it last I knew), so all the optimization we've spent the last 50 years putting into our CPUs won't be firing. You'd basically be trying to run your computer on something that would be in the range of 100MHz down to for all I know single-digit MHz-equivalent of your current Intel or AMD CPU (after all the penalties around not using any prediction, not having the proper caches, thrashing like hell in your GPU's memory caches, and all the other effects... I'm not even sure I'm willing to promise you'll never hit code with KHz-equivalent performance; you might just get that NES performance(!)).
Your modern GPU-based computer trying to boot Windows or Linux is gonna craaaaaaawwwwwwllllll. Can it do? With the right work, yeah, probably, but you're not going to enjoy it, or be willing to use it. CPUs are terrible GPUs, but GPUs are terrible CPUs.
How well a computer could run if it was optimized for the GPU is an open question, but I guarantee you that if in some bizarre parallel universe everything was running on GPU-like hardware, but in 2010 suddenly people figured out CPUs and next year the Core Duos were available, people would be flipping out over how awesomely they perform and would be rushing to rewrite huge swathes of code in these new-fangled "in-order execution units".