I was reading slides on STM32L4. Here the author explains that in each FLASH access, wait states are inserted. Then during the waiting cycles, can the CPU do something else, for example, accepting interrupts and switching GPIO pins?
Yes and no. The instruction fetch runs parallel to the cpu executing the instruction. For peripherals on the same bus interface, any bus activity is suspended whilst the flash fetch is underway - a given bus interface can only execute one bus operation at a time. Note that peripherals are still operating and can raise interrupts, but the response by the cpu is delayed by the wait states.
It can be simpler to think that the cpu stalls during wait states as this is a general approximation, especially the M0,M3,M4 with internal flash.
For the higher end parts with cache memory that further complicates the situation as the effect of wait states is somewhat decoupled from the cpu.
For example, I’ve been using a Cortex M7 part with no internal flash. Code is fetched from an external serial flash chip. I can chose to execute code from that chip directly (XIP execute in place) or copy the code into various internal memories with different performance. The fastest is zero wait state ram of which I can achieve the full 600MHz of cpu performance down to XIP which gives me about the performance of a 60MHz part even with cache enabled. The cpu is still ticking away at 600MHz, but is waiting to be fed instructions.