This is a bit of an open question but I'd like to see someone contribute a good reasoning for both.
For a quick example of both:
Interpolation Model
Think the Valve model where the client is receiving position updates frequently and the remotes update their positions using interpolation on this data.
Path-finding
In this model, think the user sends a destination and everyone pathfinds to it.
What types of games are suited to each and when should one use each?
I've worked on the networking code for two real time AAA networked games, one for smartphones and one for a handheld console.
To directly answer your question "why", well, some games use one or the other because it suits them better than the other. This depends not only on the type of game, but also on what type of network we're talking about (linked arcade cabinets have different conditions compared to games that are meant to be played over 3G) Some games actually use both, or even completely different approaches to synchronize data!
I would like to generalize, and consider not only positional data, but pretty much any type of data you can synchronize between two networked clients.
Instead of two possibilities, I would like to propose a spectrum between hard and soft updates.
Very hard updates are discrete events that immediately change the state on the other client, without any type of interpolation, either because the data is of critical nature (a player died), because it's not a type of data for which interpolation applies (an online chess game, chat messages, etc.), or because your network allows you to do that (think linked arcade cabinets where reliably sending the entire game state 60 times per second is well within the realm of possibility).
With this method, network delays will invariably show as delayed updates and manifest as characters jumping around.
Hard with inter/extrapolation updates are similar to very hard updates, but for constantly changing data, for which it is not practically possible to reliably send the data each time it changes. Think of sending a position and a velocity vector; you should be able to interpolate data between two points, and extrapolate it after them. You should have a contingency plan if incoming data disagrees with your extrapolations. I would say most games which require position updates use this method.
Hard with synchronization updates are similar to hard with inter/extrapolation, but only require synchronization rarely. You should use this for data that is really trivial to inter/extrapolate, such as the clock in a fighting game (once set on both sides, it is not really necessary to synchronize again afterwards)
Delayed hard updates are similar to hard updates, but what you're seeing is data in the past. I suspect that in many music arcade games in Japan where you can play a song against somebody else, you are actually playing against player data recorded in the past, possibly hours or even days before. Of course, this type of updates are only usable when you don't really interact with the other player.
Soft updates consist of sending planning data, and running the plan on all hosts. This is what you call "pathfinding". The amount of data required to synchronize data like this is much lower; you can use these types of updates when you can get away with certain discrepancies in how the data is presented to the user, like when synchronizing hundreds of enemies.
Planning data updates themselves can also be as hard/soft as you want, of course.
Very soft updates are used when the outcome of an action can be reliably calculated much before it happens. You just send the result, and the other client just plays it back. For example, some browser and smartphone games let you battle other people, but the actual battle takes hours to resolve (think Travian-like games). It is very possible that these games calculate the result at the very moment the battle is initiated, and you just see the results of that battle.
Another non-networked example of this would be in Civilization 4 with battle animations enabled. When you attack somebody, the result of the battle is immediately calculated, but you get to see an animation of it playing back. I can assure you the battle is not being calculated as it is being animated.
As you can see, there are many ways to synchronize data, and I'm sure you can imagine many others. All but the simplest online games will most likely use a mixture of these methods, depending on the type of data they're synchronizing, the type of game, and even the state of the network (use hard updates when lag is low, and go to softer updates when lag gets higher).
I have no insight on Valve's development process, so this is purely my opinion, but:
Interpolation: I'd say it'd be better for fast paced games, like FPSs for example, where having a consistent position for an enemy on time across players is important. Interpolating means that, even if some packets are dropped (AFAIK, most multiplayers FPSs use UDP instead of TCP/IP, which guarantees neither the integrity nor the order in which the packets arrive), you will have smooth movement on the screen.
path finding: If time is not a crucial element of your gameplay, and your algorithm finds a consistent path when re-ran, pathfinding could be interesting because it does not require that you send frequent, and thus heavy updates with the position of each single entity. I'd say this seems fitted for a turn based system for example, where you can then limit the amount of network requests (one at the beginning of the turn, one when the turn is over to make sure all clients are in a "sane" state.
Once again, I've never worked on a network game or for a big game studio, but from what I've read sometimes that's how I would go about it :)
Panda Pajama answer is pretty good.
Basically the question comes down to what is the minimal amount of data you can send that will put multiple clients in the same awareness of each others state, and how do you handle the lag where during that lag clients might be in a different state.
So procedurally generated, where all the interactions are known before hand is easiest, since if all variables are known then the outcome is known. For example isolate someone in a room, that you know the processing methods of, and give him some set of data, you can accurately predict the results. Therefore you can give every other client the results without having for them to wait for that client to finish his calculation.
However he did not mention one method. Forced results.
If the system expects an action by some entity, and other actions are dependent on that action, and other calculations take into account that action, and have already been preprocessed with that result that is expected. Then to maintain synchronization, the entire system is stopped while the one entity that is not in the right place is correctly put back on his path.
A real world example is all other entities in a holding pattern to make sure the proper compensation is sent to me.
