To an extent, this is a function of how 3D is rendered. For example, OpenGL will automatically cull geometry outside of the -1.0, +1.0 range in X-Y screen space (Z is more complex but similar). Culled geometry never generates fragments (approximately pixels) and thus is never turned into actual imagery, despite being sent to the system to render. In any case, it's impossible to write to space outside the render window (if everything is working as it should).
In some contexts, it's enough to rely on this behavior as an optimization. However, you still have to pass all your game data through at least one rendering stage (vertex shaders) before the video card can know what is visible. In something like, say, Skyrim, that would be impractical. Not only do you have to send every vertex in the world through the rendering pipeline, but you have to load every vertex into system/video memory. That's inefficient, if even possible.
So, many games will make use of CPU-based culling. They will typically implement some sort of LOD (level of detail) system, where the quality and existence of assets are impacted by how important they are assessed to be in a given context. A pyramidal mesh might be an acceptable approximation for a mountain if you're 50 miles away from it. If you can't see it at all (like it's blocked by other mountains), there's no need to even load it. There are a number of more complex methods for doing this that are topics I don't feel are directly relevant to the depth requested by this question, but look at tessellation for one of the most common examples.
The real gist of this is that the visuals are only the product of the game. The actual data has nothing directly to do with what you are seeing or not seeing most of the time, and the data is filtered by various stages to remove extraneous information before hitting the point where a picture is written to the screen. Depending on the engine design, visuals can be extremely decoupled from the actual game logic, so far as something like having a 2D and 3D interface to the same game is a possibility. It's even possible for many game engines to run with no output what-so-ever; sometimes this is used to test game AI.
That's where things can get complicated, though. In something simple like a Mario game, it is not too prohibitive to calculate the movement of all enemies in the level, even if they are not visible. In modern contexts, what is happening off-screen is an actual question of serious consideration. If there are multiple entire cities of NPCs, how do you handle how they behave when they are completely culled - like when the player is in a different city? Do you really want to be computing hundreds of NPCs' decisions all the way across the map? The answer is usually no, but the exact approach to accomplish not doing so can vary, and it can have some impacts upon the game.
It's important to note that this is how things work now. The old Mario games themselves were likely programmed in very different ways (I can't speak to the exact ways), given the extreme hardware limitations at the time. The concept of 3D did not exist back then; yet today almost all games, even ones which are entirely 2D, use 3D rendering in some form, even if they don't know they do. Modern video hardware is 3D first, and 2D rendering (at least when it makes use of the hardware properly) merely ignores the 3rd dimension.