Using the legacy ARM ISA. Unfortunate.
Said no one in the industry, ever.
In most of the target applications of these chips, you'll typically have a couple of real-time tasks. This will run on a dedicated core, or in kernel space, or with Xenomai. The rest will be firmware update services, telemetry, and maybe Bluetooth or a web GUI. Stuff where the execution speed doesn't really matter, as long as it's "fast enough". Armv7 is more than sufficient for that kind of thing.
The STM32MP2 family will probably replace the MP1 once it's in full production, but that doesn't mean the MP1 is a bad chip to use in new designs today.
The chip's competition is NXP's i.MX line of parts. If I got a good price from ST on it (and a production guarantee), I'd consider using it in a number of new products, even though the main CPUs are 32-bit Armv7 cores.
Most the USP of these is that they have an M-core which is usually where such tasks would live.
In automation it's not unusual to find controllers where the entire system lives on an MCU, and you quickly find that it's difficult to keep up with network requirements. I have devices where the MCU is 20+ years old, and the embedded TLS implementation hit a constraint 10-15 years ago.
This looks like the ideal use-case for these; your actual application lives in the M-core as it always did, but your network, TLS etc into an A-core that's much more suited to them, and where "fullsized" implementations are much more readily available.
It also benefits from established support in the whole ecosystem.