1) The 8-bit market is "dead" as in there is really very little need for new chips with more/different peripherial support. And there is a diminishing return from making chips in smaller geometries to get smaller current consumption too, since you still want large output transistors to switch current (and not just voltages) in a microcontroller.

2) It is completely wrong to think that a 32-bit processor is harder to program and requires someone to fly in. A processor you know is "easy" to program, while an unknown processor is "hard". Beginners will find just about any processor "hard". Note that a 32-bit processor doesn't automagically imply a processor with MMU and for use with an RTOS. The same strategies will work in the 32-bit code too. A 32-bit processor can handle larger values atomically (without troubles from ISR and main code changing a two or four-byte variable at the same time using multiple reads/writes). A 32-bit processor normally has 32-bit timers, allowing longer delays without extra code or multiple comparisons. A 32-bit processor can span more memory without banking or other special methods. A 32-bit processor can use pointers efficiently since it isn't limited to a few special index registers - all normal registers are wide enough to store an address. The list can go on.

For a huge number of embedded applications, it's ok to use either 8-bit or 16-bit or 32-bit, so the main decision is: what tools and knowledge do you have. But it is stupid to break the back to fight and use what you have because "changes are bad". I'm of the oppinion that every single project should be based on an evaluation of what is suitable. For a low-volume and/or low-resource project, it's best to stay with what is known. When production volume goes up or if the project has special requirements, then it really is important to do a careful analysis and be prepared to take a jump even if that represents investments in new tools or in learning new skills. No architecture or processor variant is "magic".