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.
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.