This is one of those subjects that can become highly debated. There are so many different points of view, and different things are important to different people. I will try to give a comprehensive answer, but understand that there will always be someone who disagrees. Just understand that those who disagree with me are wrong. (Just Kidding.)
Quick Summary:
This answer is going to be a long one, so let me summarize this up front. For the vast majority of people the latest crop of ARM Cortex-M0/M3/M4 chips offers the best solution, the best features for the cost. This is even true when comparing these 32-bit MCUs to their 8 and 16 bit ancestors like the PIC and MSP430s. M0's can be bought for less than US$1/each and M4's for less than US$2/each so except for the very price sensitive applications the ARM solutions are very nice. M0's are very low power and should be good enough for most people. For those who are very power sensitive the MSP430s might still be a better choice, but the M0s are worth considering for even these applications.
If you are interested in a more in-depth analysis then read on, otherwise you can stop reading now.
I will now look at each area and compare the different MCU's:
Speed of Execution
Of course the 32-bit MCUs are going to be faster. They tend to have a faster clock speed, but also do more work for each of those clocks. MCUs like the ARM Cortex-M4 include DSP processing instructions, and can even have floating point support in hardware. 8 and 16 bit CPU's can operate on 32-bit numbers, but it is not efficient in doing that. Doing so will quickly consume CPU registers, CPU clock cycles, and flash memory for program storage.
Ease of Development
In my opinion, this is the most valuable reason for using modern 32-bit MCUs-- but also the most under-appreciated. Let me first compare this to the 8-bit PICs. This is the worst case comparison, but also the best to illustrate my points.
The smaller PICs basically require that the programming be done in assembly language. True, there are C compilers available for even the 8-bit PICs but those compilers are either free or good. You cannot get a compiler that is both good and free. The free version of the compiler is crippled in that its optimization is not as good as the "Pro" version. The Pro version is approximately US$1,000 and only supports one family of PIC chips (8, 16, or 32 bit chips). If you want to use more than one family then you have to buy another copy for another US$1,000. The "Standard" version of the compiler does a medium level of optimization and costs about US$500 for each chip family. The 8-bit PICs are slow by modern standards and require good optimization. You can either fork over the money for a good compiler or you can write in assembly language-- I prefer assembly in this case.
By comparison, there are many good C compilers for ARM MCU's that are free. When there are limitations, those limits are usually on the maximum size of Flash Memory that is supported. On the Freescale Codewarrior tools this limit is 128Kbytes. This is plenty for most people on this forum.
The advantage of using a C compiler is that you don't have to bother (as much) with the low-level details of the CPU's memory map. Paging on the PIC is particularly painful and is best avoided if at all possible. Another advantage is that you don't have to bother with the mess of handing 16 and 32 bit numbers on an 8-bit MCU (or 32 bit numbers on a 16-bit MCU). While it is not super difficult to do this in assembly language, it is a pain in the rear and is error prone.
There are other non-ARM C compilers that work well. The MSP430 compiler seems to do a reasonable job. The Cypress PSoC tools (especially PSoC1) are buggy.
Flat Memory Model
A MCU that has paged RAM/registers/Flash is just stupid. Yes, I am talking about the 8-bit PICs. Dumb, dumb, dumb. That turned me off of the PICs so much that I haven't even bothered to look at their newer stuff. (Disclaimer: this means that the new PICs might be improved and I just don't know it.)
With an 8-bit MCU it is difficult (but not impossible) to access data structures larger than 256 bytes. With a 16-bit MCU that gets increased to 64 kbytes or kwords. With 32-bit MCUs that goes up to 4 gigabytes.
A good C compiler can hide a lot of this from the programmer (a.k.a. You), but even then it does effect program size and execution speed.
There are many MCU applications that this will not be a problem for, but of course there are many others that will have problems with this. It is mostly an issue of how much data you need (arrays and structures) in RAM or Flash. Of course, as CPU speed increases so does the odds of using larger data structures!
Package Size
Some of the small PICs and other 8-bit MCUs are available in really small packages. 6 and 8 pins! Currently the smallest ARM Cortex-M0 that I know of is in a QFN-28. While a QFN-28 is plenty small enough for most, it isn't small enough for all.
Cost
The cheapest PIC is about one third the price of the cheapest ARM Cortex-M0. But that is really US$0.32 vs. US$0.85. Yes, that price difference matters to some. But I posit that most people on this web site don't care about that small of a cost difference.
Likewise, when comparing more capable MCUs with the ARM Cortex-M0/M3/M4 usually the ARM Cortex comes out "roughly even" or on top. When factoring in the other things (ease of development, compiler costs, etc. then the ARMs are very attractive.
Second Summary
I guess the real question is: Why would you NOT use an ARM Cortex-M0/M3/M4? When absolute cost is super important. When super low power consumption is critical. When the smallest package size is required. When speed is not important. But for the vast majority of applications none of these applies and the ARM is currently the best solution.
Given the low cost, unless there is a good reason to not use an ARM Cortex, then it makes sense to use one. It will allow faster and easier development time with less headaches and larger design margins than most other MCUs.
There are other non-ARM Cortex 32-bit MCUs available, but I do not see any advantage to them either. There are many advantages to going with a standard CPU architecture, including better development tools, and faster innovation of the technology.
Of course, things can and do change. What I say is valid today, but might not be valid in a year or even a month from now. Do your own homework.
Best Answer
An ARM processor can not execute arbitrary sequences of interleaved ARM and Thumb instructions. It has to be switched from one instruction set to another, e.g. through a branch instruction. So most of the time you tell the compiler to use either ARM or Thumb instructions throughout your project. The best the compiler can probably do is to decide on a function-by-function basis which instruction set fits best. The Thumb2 instruction set is supposed to combine the advantages of ARM and Thumb without the drawbacks.
Edit:
The answer to the question @Kynit linked to basically also states the above.