Design Consideration: Cortex M0 vs Cortex M4 for IoT Applications
To summarily answer your central points;

In handling communication with peripheral devices selecting the right processor with the correct support for the hardware busses you are using is the most important. There are many ways to do many kinds of communication, but most SPI enabled items that you should concern yourself with as a somewhat experienced amateur will be in the 10 to 20MHz of SPI range at most.

That means that your SPI peripheral will clock out a byte for every 20-ish core clock cycles on a 48MHz CPU at the moments of highest activity. In a well designed interrupted environment that is more than enough if you're not doing huge amounts of masking, shifting, adding and dividing on each individual byte, for every single byte.

Moreover, going to 80MHz will not help you significantly there if you start chocking.

So you are much better off finding a processor with good support for Peripheral Management such as a DMA/uDMA system that's usable for large transfers and a nice hardware FIFO, if at all possible, that will hold at least 4 bytes of data (2 16bit words, or 1 32bit qword, or just 4 bytes), so you can bulk-build int32 values.

What will help you most with Real-Time considerations is understanding how interrupts work and how to efficiently use them without blocking up huge chunks of processor time. After-all, while the serial peripheral is clocking out or in data at a few MHz your core needs to not do anything about that, as long as you chose the right controller with the right kind of hardware support.

The amount of internal RAM (or fast parallel external RAM, but seriously, you don't want to start thinking about that at this point in your 'career') you need will be dictated by how much data one thing will generate in the time another thing needs to handle the output of it. If you make sure your output pipe (probably WiFi?) is fast and your sensors generate an order of magnitude less data, you won't need that much RAM as long as you manage the flow well. If you create 5kB data packages of which the start depends on the end through your own silly design, you will need more RAM than when you make it so there is no dependency outside 512byte blocks (or less).

A faster core speed will not help you greatly if all you are doing is move a few bytes around every interrupt you get. If you need super high speed SPI (which the WiFi module likely won't support if it's at all affordable anyway) you need a processor with a high-speed peripheral clock and high-speed, low-capacitance I/O pin drivers, rather than one with a fast core.

To paraphrase anecdotally: I'm now using an M4 processor to make something that could have been done with a 20MHz Atmega, if it weren't for the fact that the bus interface some numbskull specified needs very high speed Bit-Banging and FPGAs are not an option in this design. So, I am inputting let's say 5Mbps of data and outputting that over standard peripherals like I2C and SPI and all gets decoded, mathified and what not, but 70% of the time my core does something it's bit-banging the 5Mbps input and quickly deciding on bit-to-bit decisions. Take that away and I could have chosen at least an 8 fold cheaper MPU. Because almost all else is interrupt and hardware in which the core does absolutely nothing.