No, I think the engine metaphor is pretty apt. I completely understand what he's saying, but the alternative he seems to imply is no better. Why would I want the interface to load but not be able to use it for another 45 seconds? Okay, so I'm in my car (clicked on the shortcut) but I won't be able to go anywhere (use the application) for a few minutes because it's slow to accelerate (load). Who cares about the max speed of your car as long as it 0-60s in a reasonable amount time?
Either way it's going to take some time to load because it's a big application. One way lets you know it's working, the other makes you think it has frozen as you're fruitlessly clicking around. The interface is the least important thing in the application until it's fully loaded.
I think it makes sense. To extend your metaphor, you can do things such as turn on the radio without noticing a performance difference between the two cars.
The idea with Photoshop is, sure, loading the entire thing will take much longer, but users tend to use one tool at a time, and loading an individual tool shouldn't take anywhere near as long.
It also makes sense from the point of view of parallelization. One example of an extremely slow operation is waiting for the user to click on something. So instead of sequentially loading things, followed by the user deciding what to do, Photoshop should continue loading while the user decides e.g. what brush size and color he/she wants.
Like any other, this approach has advantages and disadvantages - it would indeed be frustrating if the brush tool hadn't loaded by the time you started using it, and it would probably require a lot of work for Photoshop to load so modularly and on-demand - but all I'm saying is, I understand the value in the alternative he suggests.
To go beyond cars and Photoshop, the RPG Guild Wars is a good example of only loading what you need. In fact, it doesn't even download the other game zones before you need them. If it sees you running towards the next zone, it begins a buffer in the background to pull in the data. So instead of making you wait while the game downloads and installs everything right up front, it downloads then loads up exactly what you need. This is much harder in an application, which is more non-linear.
When you run a program the OS will usually just map the code into address space, it won't necessarily actually load the code from the disk until it needs to.
It's possible that what the program is doing at initialization is not loading code from the disk but doing something else, like perhaps checking it has a nice big contiguous area of disk to use for temporary storage or for loading some type of cache into.
There are many times in programming where you make a choice between taking a one-off up front cost to optimise something for faster overall performance vs slower overall performance without the setup cost.
For example with a DBMS you can lose some write performance by having an index on a table and rebalancing when you are writing but the advantage is much faster read performance.
Also A Java program can take longer to run the first time by JIT compiling the program for the platform it is run on but this will mean faster performance of the program itself.
Either way it's going to take some time to load because it's a big application. One way lets you know it's working, the other makes you think it has frozen as you're fruitlessly clicking around. The interface is the least important thing in the application until it's fully loaded.