One common reason is that it isn't always equally easy to determine if a resource is going to be needed in the near future.
Since you used terrain paging as an example, I will continue with that.
It's perfectly reasonable if you're in a given map grid to load all adjoining map grids in the background. You know the user can, at best, enter one of those. When they do, you can unload the ones no longer adjoining and load the ones that now are. This you have noted.
Now imagine fast travel. There is absolutely no way to predict where the user may choose to go. They have (usually) almost the entire map to choose from. Pre-loading all possible fast travel locations would take far too much memory (you might as well load the whole map into memory in the first place) and far too much time (assuming you did not have the whole map pre-loaded). When would this happen? When they open the fast travel dialog? The problem would only become several times worse!
This is why even most games with "no-load" terrain paging still have load screens on fast travel. It's also why, if you move fast enough, you can sometimes trigger loading screens in even games with no-load maps (I recall having done this in TES Oblivion).
Now imagine this applied to game resources in general, where relationships are often not obvious. You will end up having to either load all possible options, or start guessing what the user is going to do. Guessing is costly (both in development and CPU) and a complex mess to program. Specific examples:
- Save files: you would need to load every save file before the user reaches the save screen, or guess which file they might load (latest 5, etc.).
- UI: Many strategy games change their UI depending on your faction. You would need to load every possible UI design before the user started their game.
- Game world: in procedurally generated games, like Minecraft or RTS games like Civilization, the world doesn't exist until viewed, to varying extents. Pre-loading this is impossible since they did not exist to begin with; pre-calculating them could at best be done similarly to pre-loading, and is not applicable in the RTS case.
There might be ways around some of these issues, but that costs real life money to figure out. Most gamers accept reasonable loading screens and, if anything, tend to be willing to spend more on hardware to mitigate them. It's seen as a hardware issue, not a game issue, unless unusually excessive or otherwise disruptive (like loading in the middle of levels).
And keep in mind, background loading is not free. There is usually minimal impact from the modern use of background-loading terrain and some model files, but if you're suddenly guessing about many different resources, especially if you don't have reliable metrics and have to unload many resources and load superfluous ones, you can grind the system into dust.
The idea of background loading is to use the dead cycles for a better use, but there are only so many dead cycles to use. The same goes for memory - pre-loading can substantially increase the memory usage of a game. With a loading screen, you get to dump the existing resources. No such luxury with background loading, meaning it could double the memory requirement of the game on that count alone.