Seeing as how I've done this a few times in the industry, here's my rule of thumb:
Always, always implement dynamic "on-demand" pathfinding first, because it's simpler, faster to code, is much (MUCH) easier to debug, is more flexible, and has fewer moving parts (doesn't require changes to file formats, makes fewer demands on the data pipeline, etc).
I'm currently working on a commercial racing game which has fixed but branching tracks. Even though each track might only have four or five possible routes to reach the finish line, each car (8+ of them) is dynamically generating its own path from the starting point to the finish line, independently from the other cars. You might call it a waste for the cars to generate these same paths over and over again. But it's not -- it's simply faster and easier for me to code it this way than to bother with doing it as a pre-process, which means I can spend more of my time on things which actually will be noticed and valued by the end-user. Or to put it differently; we're trading a vanishingly small amount of CPU time for a whole lot of my time.
Pre-building paths is a form of code optimisation, and as such, you really shouldn't be thinking about it at all until profiling has shown that the dynamic approach is actually having a measurable impact on performance. In many (most?) cases, it doesn't. And so the fast-to-implement and flexible "dynamic, on demand" approach should always be preferred, until concrete profiling shows otherwise.