Floating or fixed point precision would have caused this problem. Older games commonly used fixed point as it was traditionally faster than floating point, prior to widespread FPU support in consumer machines which began in the early 1990's. (The Intel 386SX / DX gap showed the floating point performance difference clearly in a game like Doom which relied heavily on fractional numbers.)
Consider a range of numbers which uses only 1 decimal place. If every full unit were to represent a metre, then every decimal place would represent a tenth of a meter (AKA a decimeter). Since this is your maximum precision, objects will obviously jump in increments of 0.1m, rounding up or down to the nearest decimeter as necessary.
Fixed point is how we tend to traditionally think of decimal point numbers: numbers that can be represented down to some smallest fraction of a single unit (as in the above decimeters example). However, given that every number must be stored in a certain number of bits (for modern IEE-754 floating point, a commonly-used standard, this is 32 bits or 4 bytes), we have a limit on precision for what sits to the left of the point, i.e. the significand, and what to the right of it, i.e. the fraction.
Now, given n total bits in which to store such a number, we have two choices.
- We can choose to use x of n bits to store the upper part, and the remaining y of n bits to store the lower part, in a fixed point format (eg. 16.16 fixed point, a total of 32 bits used). This is conceptually simple, but not space-efficient.
- Floating point offers another option, and this is why it is named "floating": The bits can be used in a variable configuration to provide a much larger range, at the expense of whatever is on the other side of our "floating" decimal point. Range for the fraction comes at the expense of the significand; and vice versa. Given this, one can see how smooth movement over galactic (or greater) distances is possible in simulations (googling single-precision floating point range" will indicate just how large a range 32-bit IEEE-754 can support, never mind higher-precision standards which use 64- or 128-bit words.)
This should give you some indication as to why in this age, where even low-spec mobile devices now support floating point arithmetic, we no longer have the aliasing effects you describe.
As for the vertex issue, I find it likely that this is due to the fact that before GPU tech became widespread in the days of 3DFX, it may have been common to duplicate vertices, possibly because getting a good winding order along with linear (and thus efficient) data access is not a particularly trivial problem and it may be easier for performance reasons to simply duplicate most vertices so that each triangle consists of 3 unique vertices... this would positively impact cache performance at the very least. In that case, vertices might be matched in any of a number of ways, from manual entry to precalculated positions for different orientations to runtime calculation. But I am going to hazard a guess that this sort of thing is unique for every game. I remember games which simply didn't do this at all. So it is likely this was a specific quirk of individual engines that occurred for different reasons.