As technology keeps improving, is there any way Sony can make a handheld PS4, or create some easy pipeline to convert PS4 games to the hand held, with minimal work, if any at all. X86 portable seems to becoming more possible.
As for Switch Pro, whatever you expect, cut it by half, then cut it by half again and still be disappointed.
The weakness of x86 is always going to be power consumption. There are a couple of reasons for this - one is that it's fundamentally a processor with a register/memory architecture and hence it hits the memory pretty hard and needs both short access times and low latency. In practice (especially with the large working set of modern software) this means you need a very fancy cache system, and that takes significant power. On top of this, if you look at the internal architecture of modern x86 chips they basically consist of an instruction decode section that decomposes the x86 instructions into simpler operations and feeds them to a set of execution units that look very similar to the ones in a RISC CPU simply because to retire instructions at the rate needed you have to keep things simple. The problem is that to make all this work you need long pipelines and very complex logic for keeping track of what's currently in progress, especially when you get into things like speculative execution, since if you end up needing to revoke an instruction you have to unwind all of it's effects, which hence need to be kept track of. All this also adds to the power consumption.
The reason that mobile devices have overwhelmingly chosen ARM is the flip side of this - ARM is a load/store architecture where memory is only accessed when the programmer (or compiler) explicitly requests it. It has a large register file and an highly orthogonal instruction set, so you almost never have to move stuff around to get it where you need it to work on it. The downside is that the instructions have lower semantic content and hence on average you need to process more of them in order to carry out a given function - this obviously increases the load on the memory, but in practice this is more than offset by the reduction in memory accesses that aren't really needed but just imposed by the architecture. Another consideration is that you no longer need to decompose instructions on the chip in real time - the corresponding operations are carried out once by the compiler where they don't impact the power consumption at runtime - and the compiler can usually do a better job anyway since it doesn't have to run in real-time and can analyze the code to a much deeper level than a runtime translator can. The pipelines are shorter and hence the penalties for mispredicted branches are smaller and because most of the instructions operate purely on registers you can handle speculative execution using register renaming and scoreboarding, which is much easier to unwind.
Basically, trying to make a low-power consumption system using an x86 is a bit like repeatedly punching yourself in the balls and then wondering why it's hurting.
Note that I'm certainly not trying to suggest that x86 is a terrible architecture (well, not since the i386 anyway...) just that it's not a good choice for low power systems - especially with a closed system like a console that doesn't require binary compatibility.