Of course the Raspberry, by running standard Linux, has non-deterministic timing and lag easily in tens of ms, and worst-case lag in seconds (or of course it can completely crash), but adding another layer does not solve this. If the Raspberry does something based on messages on CAN, or generates messages on CAN, what can you do except accept the lag?
If you can use the intermediate microcontoller to perform some part of the tasks Raspberry would otherwise need to do, specifically all the timing critical ones, without the Raspberry, then it would make sense to add that layer. Otherwise, I don't see the point.
The usual SPI CAN bridges have some buffer memory, like 2KB, and this should handle the delays of linux kernel in 99.9999% of cases but be aware that using linux, it's impossible to absolutely guarantee the timing so buffer overrun is always a theoretical possibility, but I think adding another excess layer just to add more buffer memory is more risky bug-wise.
Likely, the SPI-based CAN controller directly on the Raspberry SoCs SPI, using the kernel driver module, is quite fast and reliable. I don't think you can do any better with any other interface on the Raspi.