Earlier quoted context omitted.
I haven't yet worked on automotive stuff but I work in the embedded space. We're using small MCU (not CPU) to drive 480x272 or 800x600 screen. 240Mhz, 8MB of RAM. For example on ESP32-S2 or ESP32-S3. If you had GPS, bluetooth, wifi, etc. to the mix, yeah that's a challenge and you need to make your UI pretty simple.
Nearly everything automotive now has a GPU. When you have a GPU, even a very low power one, graphics get far easier. simple operations like "fade from this screen into that screen at 60 fps" become easy. They would be impossible with CPU graphics, simply because a slow CPU can't update every pixel on the screen at 60 fps anyway. Despite that, automotive graphics ramain laggy because they normally build something bare…
Basically anything that involves copying pixels or solid fills without per-pixel calculations. 60fps at 800x600 is 28.8Mpixel/s. Copying and filling at that rate should be achievable by a 240MHz CPU with some tight coding. The rest is 2d geometry, mostly axis-aligned, with relatively few edges. That's not demanding at all.
(I used to write 2d and 3d rendering engines for slower CPUs than that.)
A GPU is necessary for fancier effects like fades and shading, but the basics can be smooth on a CPU and the fancy stuff too if confined to smaller areas.
Also, for the car, people would be happy enough if it could do a consistent 30fps I think.
Those annoyingly slow GUI updates you tend to see on TV set top boxes are not slow because of the hardware... it's usually the software not being written with sleedy rendering in mind.
All that said, you're right that if there's a GPU or even just a Blitter, it should be used and then the CPU speed almost doesn't matter as the geometry calculations are so simple.