Only having two UARTs can be limiting - and PIO is a no-go if you want offloaded parity checking and flow control. The PIO doesn't have an easy external clock input. No CAN or Ethernet makes usage in larger systems tricky. There's no USB Type-C comms support. Its ADC is anemic (only 4 channels, with 36 io pins?). There are no analog comparators. It doesn't have capacitive touch sensing. There's no EEPROM.
None of them are direct dealbreakers and you can work around most of them using external hardware - but why would you want to do so if you could also grab a MCU which has it fully integrated already?
is 2.5ns (https://github.com/gusmanb/logicanalyzer) to 3.3ns (https://github.com/schlae/pico-dram-tester) resolution not enough for you?
On a STM32 you can just set up the timer and forget about it until you get a "hey, we saw a pulse at cycle 1234" interrupt. The two are not the same.
My argument wasn't "this is completely impossible", but "this is needlessly complicated".
What Pico/RP2040 projects do instead is use a PIO state machine clocked from the system clock to deterministically timestamp edges (often DMA’d out). It avoids ISR latency and gives cycle-accurate edge timing relative to the MCU clock. It’s not a built-in capture peripheral, but it achieves the same practical result.
If you want a drop-in hardware capture block with filtering and prescalers, STM32 is the better choice. RP2040 trades fixed peripherals for a programmable timing fabric.
> nontrivial applications
Out of curiosity, where do you find that you’re hitting the limits of what it can handle?