but then so wouldn't a rumored 15" MBP and a 16" MBP. Apple doesn't seem to care too much about one product cannibalizing another
I think the rumors that
make sense are of a 15" M2 MacBook Air alongside the 16" MBP - for people who just want more screen area for undemanding work without needing the extra CPU/GPU power and I/O capability of a Mx Pro/Max chip (for which Apple charge quite a premium).
In any case, consumer MacBooks sell in multiple millions so Apple can afford to spread that between multiple overlapping models (or the 13" MBP wouldn't exist and the M1 Air wouldn't have hung around). Desktops probably sell a fraction of those numbers so too much overlap would make some models uneconomical (by Apple's standards, not those of a smaller enterprise - they probably don't get out of bed for sales of less than a million).
BUT... Without support for AMD GPUs, are the slots necessary.
Plenty of other uses for PCIe slots - M.2 storage, specialist audio interfaces, Fibre Channel, heck even adding a load of top-level USB
2 ports to drive MIDI & audio devices with low latency (TB docks tend to end up connecting USB 2/3 devices via under multiple layers of internal hubs shared with other devices). If you have the slots, pretty much any such functionality which you
could connect externally via Thunderbolt can be done more cheaply, neatly and reliably by plugging in the appropriate PCIe card.
However, its GPUs that tend to actually benefit from x16 slots whereas a lot of other uses would be viable in a TB-to-PCIe enclosure - and the 'clutter' issue could be addressed by rack mounting everything (spendy - but so is a Mac Pro).
The question is, how many "pro" users who rely on PCIe slots
mainly for supporting existing hardware are actually ready and able to switch to ARM, or even to be forced onto the latest MacOS, which may not support their existing devices or specialist software? If you're starting a workflow from scratch, doing everything with new, external thunderbolt/USB-C devices (possibly rackmount) might be viable.