From Table 7 you will deduce that all 2x4 data lines, both chip selects and clock are available even in LQFP100, so it's possible to use two paralleled spi flash devices in QPI mode. For DTR chips this will give 1 byte per clock edge, so this could be pretty fast.
However, using all 11 pins for flash might severly impact availability of other peripherals, so you have to check that for your application there is no conflict.
The performance penalty is impossible to predict. For pure sequential access, you can calculate the throughput as above. But if you need big data areas with random access: each single byte read requires one byte instruction, 3 or 4 address bytes, some dummy cycles, and the actual read, so ...
When the flash is memory mapped, it looks more or less like internal memory, so debugging is not affected except for soft breakpoints, as the actual instruction is temporarily replaced by a breakpoint instruction. I don't know whether any debugger is aware of external flash and could handle this. But single-stepping, hardware breakpoints are no problem.
For ST-Link and STM32CubeProgrammer (and probably anything else): As the pin mapping is variable and the various flash chips differ in some details and do support different modes (one-line, two-line, ...), you can't expect those to work "out-of-the-box" with the external flash. You will have to provide your own board/chip specific external loader, there are already a lot of postings here regarding this. Or you could use openOCD with either this
http://openocd.zylin.com/#/c/4321/
patch or that one
http://openocd.zylin.com/#/c/4760/
Regarding program/read speed: This depends heavily on JTAG/SWD clock. But as long as your code doesn't exceed 1 or 2 MBytes in size, that's no real issue. But mass erase gets a bit slow ...
For the H7, L4+ and MP1 there is a hardware issue (probably exactly the same for all of these three families): Avoid accessing the last few bytes in memory mapped mode, or set the FSIZE field to a higher value than the actual capacity: The last byte is incorrectly read as 0x00, and too persistent accesses to the last few bytes via debugger causes the debug interface to go berserk. For me (Nucleo with STLink) the only cure was power-cycling the board.
