My issue generally with these flash parts is price/availability, having been burned on a number of occasions, I'd provide for as many options as possible.
If you have a couple of favoured parts consider putting down a dual-foot print of the SOP16 300mil / 7.5mm with a SOIC8 at 90 degrees inside the larger land-pattern.
Keep the signals relatively short and equally lengthen. Some of the these parts will happily clock at 100 MHz
Not sure how many pins your display uses, but perhaps look at the 100-pin H750VB device, it can support two QSPI, and has a lot of internal SRAM
Most of the QSPI circus is with the write/erase, not sure the application needs all this. Might need to consider if needing to do field updates.
The read/xip setup does take a little work, but I think one could probably code a library that could use the JEDEC READ ID and adapt sufficiently. Realistically over the life of a product you might expect to use several devices in production as availability and prices change, or new steps of the silicon add more/different features.
uBlox has long used QSPI memories, their approach was to keep all the chip specific stuff in a 4KB sector such that the ROM could boot-strap into the first few sectors, and then code selectively placed their by the update utility would manage the specifics of Winbond vs SST vs Macronix, etc.
