I mean 'several cheap MCUs on the same board connected over a single-master-multiple-slave SPI link', not multi-board or multi-core systems.
I'd use I²C because, as opposed to SPI, it does not mind waiting.

This matter has been discussed here occasionally; people usually agree that a multi-cpu design makes more sense the more loosely coupled the CPUs are.
Do not know about 'people' but I do

For me, the main advantage of a multi-cpu system would be that the software would get neatly partitioned into much simpler and independent units, making it far cheaper in development time. For example, instead of running several concurrent, loosely coupled state machines on a single CPU, you would have each state machine run in a separate CPU as an almost trivially simple task.
The main advantage, in my opinion, of multi-CPU as opposed to multitasking is independent timing.

So the idea looks promising in principle. But are there any potential pitfalls or caveats a first-timer should look out for? is this really as good an idea in practice as it sounds? Am I going to regret it?
be very careful in your partitioning before you start out. Multi-CPU will require a new hardware if you need to move a task.

For example, as has been mentioned in other posts, some of the things that can get messy are OCD and IAP; looks like I'll have to chain all the CPUs on the same JTAG link and make sure the debugging/programming software supports that scheme, or provide a separate connector for each MCU.
have only done this with SILabs chips, works, at least for SILabs, as a charm

Erik

PS in your scheme I have used up to 4 processors. My total systems have ranged for 1 tp 57 processors.