The parallel interface might be faster (check the ILI9341 datasheet for actual timings), SPI needs fewer pins, so you might be able to use a smaller package.
EmWin supports any interface that can display pixels, but it has no way to know how did you connect your display hardware, so some driver code must be written or adapted.
I don't think there would be many ready-to-use examples for the STM32F427, because people tend to use STM32F429 instead, which has a dedicated TFT-LCD controller (and 100% identical otherwise). There is an STM32F429 discovery board made by ST, which comes with a few ready-to-use examples. There are a number of sample projects out there for other STM32 MCU families, which could be adapted with various amount of effort.
On the other hand, EmWin is able to draw directly to the MCU or SPI interface, not needing memory for the framebuffer. But without an internal framebuffer, Chrom-ART is not really useful.
There are a dozen ways to do this, the best choice depends on your requirements and priorities. E.g. if the top priority is not having to understand how it works, just drop in a "sample project", use the STM32F429/Discovery as a base. You might be able to leave the external SDRAM out, if the program doesn't need animations or a lot of data storage, as the framebuffer would take up 150 of the 256 kbytes internal RAM.
