It doesn't matter if you talk about single-bit or multi-bit operations. We are not talking about 32-bit general-purpose processors, but processors intended for microcontroller use. Many of the 32-bit processors have memory mappings allowing the program to specify one port address to read 32-bits. A different address to read the low 16 bits. A third address to read the high 16-bits. A fourth address to read the low 8 bits, ...

An NXP LPC23xx or LPC17xx can manage an 8-bit or 16-bit read or write just as well as it manages a full 32-bit access. And the LPC17xx can continue this by having 32 unique addresses to just read or write a single bit. When needing to get the third and seventh bit, no normal processor will have such a dedicated instruction, so it'll be time for normal and/or operations. A 32-bit processor then automagically get the freedom to and/or 32-bit masks making it able to match and surpass any 8-bit processor. There are also 32-bit processors that can perorm a mask operation directly on the memory read - an advantage of having larger instructions and hence more bits available for the instruction decoder.

A 32-bit processor can always be built to match any instruction set you can have in an 8-bit processor. Look at the instruction sizes of the 8051. They can be implemented in a 32-bit processor, and there would still be ample of instruction space left for adding full 32-bit instructions.

So there can never be a general rule that a 8-bit processor can have an instruction set that can not be matched by a 32-bit processor.

It is easier to build a fast 8-bit ALU than a fast 32-bit or 64-bit ALU, so in theory you would be able to build an 8-bit processor that could run at a higher clock frequency than a 32-bit processor. But in the real world, we already know that few 8-bit processors reaches past 100MHz - there isn't enough driving force for taking the costs to produce extremely fast 8-bit processors since a program that needs such high speeds normally also needs the type of computation performance that improves with 16-bit or 32-bit operations, doing a single add instead of one add and three add-with-carry. Right now, the absolutely fastest 8051 implementations are sold as cores for incorporation in programmable logic, for customers who have already decided to take the extra cost to get custom hw acceleration.

In the end, it all comes back to the simple rule that you can find a specific 8-bit processor that can beat a specific 32-bit processor when doing a specific operation. But that is a specific case that can not be extrapolated - there are no physical limitations stopping a 32-bit processor from implementing the exact same instruction and processing that specific instruction in the same number of clock cycles, or even supporting superscalar operation.

In the real world, there are economic factors that limits the availability of too fast 8-bit processors, or 8-bit processors using the smallest geometries. At the same time, there are economic factors that tries to make 32-bit processors have as well-rounded instruction sets as possible, which is a reason why you don't normally do a "80351" 32-bit processor. The 80251 chip does exist, but didn't manage to deliver enough to make it take reasonably amounts of market share. A badly selling 80251 hasn't inspired the processor manufacturers into trying to copy the 8051 instruction set into 32-bit processors. But they are extremely interested into getting huge performance/mW from their 32-bit chips, so even if you do find 8051 instructions that can't be directly matched, you will find that the 32-bit processors are very, very fast anyway.

Every month, new interesting processors gets released. We can't design based on 10 year old truths. We have to look around, all the time. In some situations, the critical factor is how much flash or RAM we need. In some situations it is the number of nWh needed to perform a specific task. In some situations we need to operate concurrently on many I/O signals. All we know is that the price of the processor does not reflect the number of transistors in the core, or the size of the flash or RAM. And the number of transistors does not reflect the current consumption. So as professional developers, we just have to chose a processor based on some "best for the task" score, and not just based on "is my faviourite". Is the processor (cost, learning time, speed, current consumption, availability now, availability 5 years from now, tool quality, ...) a good fit?

The above can basically lead to one of three things:
1) we end up working with a lot of different processors, since the needs are so different between projects.
2) we end up cherry-picking projects to just do projects that fits reasonably well with our favourite set of processors.
3) we use our favourite processors weither they is good or bad for the task, sometimes producing substandard products because we were too stubborn.

I tend to end up in the first group. One project may use an 8051. The next an AVR. The third a PIC. The fourth a PPC. The fifth an ARM. For some reason, I have never done a commercial project with any MSP430, but hopefully one day... It doesn't bother me if I have to learn a new processor, as long as the required tools are commercial grade. I'm not too convinced about the tool quality for the PIC chips, but that is something to save for a different thread ;)