Games run in discreet time steps called frames or ticks. Bullets travel can then be simulated in several ways for example using numerical integration to apply forces to each bullet for the time step to calculate its new position, collision testing the line segment (“raycasting”) between the position of the last frame and the new position and calculating and displaying the results.
You have spent the past month or three writing and optimizing some very slick code that draws a first-person view of a maze, with textured walls and floors. Everyone's jaws drop when you show it to them. It takes about 75-90ms to draw a frame on that 80286.
You have next to no time left to run game logic in. Simulating a handful of active enemies and processing player inputs pretty much eat up the rest of the time. But you have this raycasting routine that you optimized the hell out of because it's in the middle of one of the hottest parts of the display-rendering code. So you reuse that as your "is the player aimed at an enemy when they clicked" check. It's good enough, especially since the game's largely set in a tight labyrinth with few spaces large enough that a more realistically simulated bullet wouldn't get to your target in the time between one frame and the next anyway.
When you upgrade your view renderer to handle non-grid-aligned walls and arbitrary heights for your next game, you don't bother simulating better bullets. It's still Good Enough - you're targeting a faster CPU now but you're still doing all the rendering yourself because GPUs don't even exist yet, and your rendering is more complicated now and you still only have about 5% of the CPU time left for game logic.
You start licensing your view renderer to other game companies. ("You", in this story, are pretty much John Romero.) Other people start writing similar game engines but they make similar decisions for similar reasons; "realistic bullet physics" would be nice to have but that's a lot less impressive than "this game can actually render objects with a triple-digit number of polygons while maintaining a decent framerate and resolution".
This situation persists for quite some time until "3D accelerator cards" become something you can expect the average computer owner to have, and you can start spending CPU time on "simulating a more complex world".
(It is also worth noting that 2D games written in this timeframe would generally show bullets as visible objects with an exaggeratedly slow travel time, so the player had a chance to dodge them. Rendering 2D stuff is a lot cheaper.)
Doom did a lot better, hence the monster infighting
HN users tend to think deeper/more complex simulation is directly correlated to better gameplay (see the sword conversation above), but one of the interesting things about games is abstraction.
That said more simulation focused games with larger maps (some Battlefield games, ARMA) have bullets with travel velocities and bullet drop.
Raycasting instead takes the light-speed-line information and runs some process like "What could we do to make this play out convincingly?" Then based on that information, it adds the gravity effects and other stuff to what plays out.
You might raycast right before a jump to determine what landing animation your player will ultimately use. That's important during the jump because it makes it look more convincing.
Precomputing a trajectory loses the dynamics of collision and the cheapness of rays.
Fixing projected actions into the future from one point in time can make for weird lag effects and unpredictable results for the player when a moveable piece interrupts a fixed bullet path.