Your sentence would have been meaningfull if you had written "There really are things a specific 8-bitter can do more quickly or more easily than a specific 32-bitter.

Truth is that 8-bit or 32-bit is just a question of word width. It does not say anything about architecture or instruction strengths/weaknesses. But a 32-bit processor normally also have a wider memory interface, allowing for wider instructions. This means that a 32-bit processor can support more instructions without requiring extra, sequential, transfers from the code space. And the larger address space allowed without paging or other things means that it can match - and win - over an 8-bit processor not only in richness of instructions, but in possible algorithms. There are no magic rule that says that because a 32-bit processor can manage larger problems makes it lose when handling smaller problems. In some situations, it can match the power consumption of an 8-bit processor by using smaller geometry and hence less capacitance to overcome. In other situations, the smaller geometry will make it more sensitive to radiation, as noted by Jez.

Take a 32-bit ARM processor for example. The procesor doesn't have the dedicated bit instructions of the 8051. But in the Cortex-M3 variants for example, each bit is given its own memory address, allowing the processor to see a 32-bit port as either a single 32-bit integer, or as an array of 32 32-bit integers. That is a powerful work-around for getting the hardware to isolate individual bits on read or write.

There really are no "one size fits all" and there really are no "an x-bitter will always win over..."

Developers who don't constantly keep their eyes open and constantly reevaluates "known truths" will regularly produce substandard products.