Raspberry Pi 5: available now

1. VQFN package is a pain to deal with. You can't use a soldering iron, so its reflow-only and therefore requires hotplate + reflow hot air to deal with. Due to the difficulty of rework, you likely can't use the soldering iron+solder wick technique to fix solder bridges, for example... and therefore also require a soldering stencil to work with (gotta deposit the correct amount of solder-paste and hope everything works out good). Inspection requires X-Rays as well because everything is "under" the package, so you can't even visually inspect your joints.

I definitely prefer TQFP (seems to be the package with the biggest inventory in practice), and enjoy even the larger SSOP or even SOIC packages available from some competitors. All competitors offer VQFN as an option as well, in case you are truly size-constrained. But in my experience, a 9mmx9mm TQFP-32 is perfectly fine (7x7mm raw, but the leads take up another 1mm for total of 2mm added on the two sides). Your 32-traces are going to take up like half an inch of routing space anyway, so its not like the 5mmx5mm VQFN saves much space in practice IMO (IE: You'll need 6-layers or something... and/or to cut out lines to really take advantage of the space-savings from a VQFN)

Note: Hobbyists _should_ be using hotplates to do the bulk of their surface-mount soldering jobs. But accessibility to soldering iron for rework / touching up problems is a huge advantage to TQFP.

2. 0kB of on-board flash. RP2040 requires external components to boot, complicating the flashing / loading / bootup process.

3. Poor sleep specs, for a microcontroller. Your typical AVR DD (modern ATMega), or STM32G0, or Ti MSP430 / MSPM0 are all in the dozens or low-hundreds of microamps sleep (with some competitors in the ~hundreds of nanoamps for deepest sleep states). RP2040 sleeps at ~0.5mA to 1mA, an order of magnitude more power.

4. Poor power specs, for a microcontroller. Your typical AVR DD, SAMD, STM32G0, Ti MSP430 / MSPM0 are maybe single-digit mA (under 10mA across the board). RP2040 is like 20mA. I kid you not: an 8-bitter like AVR DD can be going full-tilt at like 4MHz or 8MHz and still have less power-usage than RP2040 *at idle*.

5. Lack of peripherals. RP2040 has PIO and SRAM as superpowers... but its got fewer timers, ADCs, DACs, OpAmps, Comparators, than all of its competitors.

---------------

RP2040's main superpower is its 264kB of SRAM. If you need gobs and gobs of SRAM, RP2040 is probably the right choice.

All other situations? I'm pretty sure you'd prefer a 12-bit differential ADC with 16x gain (ex: AVR64EA48), or 12-bit differential ADC (no PGA) + 3x OpAmps (ex: AVR128DB64) and multiple comparators and 4x onboard Vref, or 2x Zero-drift OpAmps + 1x general-purpose OpAmp (ex: TI's MSPM0 line).

Honestly, I'm not impressed by the Pico for general purpose use. The Pico works as a specialized compute-device (high SRAM, high MHz and dual-core), but this is simply impractical for many applications. You'd really rather have ADCs or Comparators in more typical electrical designs. Combo'd with the high-power usage (probably from all that redundant RAM the RP2040 has), and its difficult to recommend.

--------

Going in the other way: Cortex-M4F cores with a floating-point unit, even at 64MHz, will be much-much-much faster than a 200MHz RP2040. Why?

Because hardware float32 matter.

Why do you have 264kB of SRAM when you don't even have a floating-point unit? The RP2040 can't even be a good DSP-like system with all that compute power because you gotta software-emulate floats.

So if you _actually_ need compute power, you'd probably should be picking an STM32F4 (aka: Cortex-M4F) processor instead. RP2040 sits in this awkward zone where its got gobs of SRAM + MHz but is stuck on Cortex-M0+ (lacking floats, and other key instructions), so it doesn't actually have very fast compute in a very common case that matters...

So yeah, RP2040 works if you're willing to rewrite to integer-fixed point... if you don't need peripherals like ADCs or ACs, if you're willing to spend more power and complexity (due to the lack of on-board Flash), and are willing to use leadless VQFN packages. Its... quite a niche IMO.