I think everyone's missed the point. How many bits wide a CPU is considered to be is about how wide the registers are in the CPU, not about how wide the data or address busses are.
Motorola's 68000 series processors were all 32 bit, despite have either 8 bit or 16 bit wide databases and 16 or 24 bit wide address busses (68000 had a 24 bit address bus, 16 bit data bus, 68008 was the same core but only had an 8 bit external data bus - the 68000 would simply make two memory reads to fill a 32 bit register, but all opcodes acted on 32 bit operands in 32 bit registers).
The value of widening the registers is that you can manipulate bigger, or more precise numbers in fewer steps. I guess if we're dealing with numeric values, then the value is in the fact that you can represent a real (floating point) number much more precisely with more bits, which means numeric applications that require very tight tolerances can do their sums in fewer steps, meaning much faster processing.
Number crunching is not the only important thing though. We often use bitfields, and if you have to shift left, shift right, xor, and etc loads of bits, then obviously the more we can fit in a register in one go, then the fewer instructions are needed to complete the task and therefore the faster it happens.
All that said, I doubt there'll be a hurry to get 128bit to the mass user desktop market. Instead we'll continue for a while on the trend of going multicore. For general use the need for the kind of precision afforded by 128 bit registers is so infrequent that we can live with it happening over multiple steps. The more pressing matter is the fact that we multitask much more than we used to, whether we realise it (eg loads of apps running at once) or not (loads of services and multithreaded apps). Going multicore gives fills that need, because a single core has the added overhead of task switching, so more cores are the way to more power for now.
As for multithreaded programming being hard, it's not really, its just different. Us older ones come from a background of procedural programming, so its a bit of a change in thought process to go multithreaded. The younger folks are lumbered with the cumulative knowledge and experience of the older folks, so there's still not that much good info out there about multithreaded programming, but we're getting there.