There's a long and a short answer to the question.
Short answer:
Due to limitations and pushing graphical boundaries in modern games. Numbers in programming have limited accuracy so when you see the edge of track at say 12.001 and the edge of the grass at 12.000 in world space, that would cause a visible gap if you have the resolution high enough. That's why aliasing stops it as it essentially blurs pixels around the gap so it's much much less obvious.
Longer answer:
Problem number 1:
Floating point limits! Okay so in 32-bit graphics, floating point numbers represent a number which can be represented using 32 zeroes and ones in binary (will get relevant as I finally get to my point... my floating point (herp derp)). If I remember right, 1 of these represents positive or negative and 8 of them represent an exponent (generally speaking). If you include exponents, the maximum value is something daft like 3*10^38 (I can't remember tbh, it's been a while since I looked at it) but if you don't, you're left with a maximum accuracy of 2^23 (8.4 million ish). The reason this is important is that these exponents, whilst the first say 8 digits may represent something you can use, that *10^ bit means all you're going to see is zeroes for the rest of it. If you want to represent a number 20 digits long counting from 1 to 0 repeating, what you would end up with is something looking like '12345678000000000000'. Thus, for anything large, you're golden for accuracy but for anything small, you're screwed...
Its worth noting that 'floating point' numbers essentially mean that the decimal point itself can be placed anywhere along the number by use of exponents. If you have an exponent of 10^9 or 10^-9 and use it on the number 123, you represent the very large of 123000000000 OR the very small of 0.00000000123. The problem comes again, with accuracy. This exponent affects the value in ONE of these ways so you have to either choose to represent the very large or the very small. For a predominant example of where this becomes a problem, try and think of representing a planet in a solar system. The Sun is at point 0,0,0 and the Earth revolves around it at 149,600,000km. Well if you can only represent floating points using 8 potential digits, you either have to accurately show the Earth around the Sun or objects on the Earth, otherwise when placing things on Earth the best accuracy you may get is about 10km as a worst solution. Note that generally, a camera moves around a game world rather than the game world moving around a camera so if you're at 10,000x10,000x10,000, that's four digits of accuracy you've lost already.
Problem number 2:
Okay so this is less of an issue but it's to do with your screen and amplifies the above. So lets presume you have person A rendering at 320x240 and person B rendering at 1920x1080 and you have the issue listed above. There are two mythical objects 1m apart in terms of how you're trying to represent them. Also assume they're 1cm cubed for ease of representation.
Person A has the same field of view BUT because he has a low resolution, say he only sees these objects, despite them being 1m apart, as 1 pixel (wildly inaccurate but look at it as a ratio for ease of explanation). Person B comes along and because he has a higher resolution, he would see them as almost 5 times as far apart because he has five times (ish) the number of horizontal pixel accuracy. The illusion for Person A is that these objects are right next to each other but for Person B, there is a gap in between them. This, coupled with Problem A, is why you see these dots you see and the higher resolution you go without anti-aliasing, the worse the problem will become. Try a much older game at HIGH resolutions and you will see this a huge amount because they never accounted for the accuracy of modern resolutions, especially at 4k.
Okay so you have a woooorld which cannot be rendered in detail but how does that relate to a racing game?
Modern racing games in particular are trying to mimic accuracy and 'feel' of the road by making it so that every single rendered frame, you're as accurate as possible in knowing exactly what road surface is under your Tyre as possible. It's significantly more important in a racer than any other game type I can think of at the moment. These are ridiculously accurate, now getting to the stage of mm rather than cm or m and you can visibly see it in games now. As a result of this, when rendering said the track and the grass next to each other, these items are placed as close as possible in accuracy to each other as they can possibly get. Instead of saying track start at 12.05 and grass start at 12.05 units, they will push the boundaries of just how close they can place them for more accuracy.
When this becomes apparent is in trying to see the exact position of the car and its movement on track. If for example you are travelling at 5m/s but the accuracy is only capable of rendering to the closest metre, you are either going to be seen as travelling 4, 5 or 6m/s which would be unplayable and broken. If you breakdown this to get as accurate as possible, say with a km cubed track, you may be able to represent it as 4.9999, 5 or 5.0001 m/s which is fantastic in most peoples books. The closer this accuracy gets, the smaller the possible track size you will have, otherwise you loose out of the upper OR lower limits of this accuracy. Bigger track? The less accuracy in rendering and calculating distances traveled. This is hugely important for acceleration calculations as well as grip levels...
FINALLY I get to my point. There is another issue which is very apparent in some games but not others whereby rounding up or down of these inaccuracies can cause huge discrepancies in lap time. I don't mean to pick on the game because I loved it for close league racing but F1 2013 is the game I experienced it most. When it first came out, those who had higher FPS, got better track time. It was as far as I could tell, because all of these inaccuracies were rounded up. Therefore, say at 60fps instead of jumping from 5m/s to 5.001 m/s, they would instead jump to 5.01 (this isn't an accurate portrayal, only an example). The problem is that once this is coded in the first place, it's bloody difficult to reverse it. I think they resolved it by rounding down instead of up. As it is more difficult to corner a car at low FPS, this ended up stopping most peoples annoyance because it base-lined MOST issues but it still remained when fast racers went to lower FPS on purpose to gain an advantage. Lower FPS racers were faster in a straight line but didn't have the feedback to corner as effectively... still with the case of it being an F1 game though, it meant they were brutally difficult to overtake.
There are ways of tricking this system but they all compromise the possibilities of accuracy, thus why you don't currently see any open world game with AC levels of physics and detail... it just isn't currently possible with modern home computers. You can test this by trying to make a massive 100km track in a sim. Even if it is a straight line, there will either be a limit, or there will be a point at which your car will start warping around the world.
I realize there are ways around this... it's difficult to explain without diagrams/talking to people but I hope this helps. My written descriptions I know are extremely lacking but I'm trying to improve them, hence this post. If you want an example of this issue, I didn't know about it in 2013 so I tried to make a solar system simulator without taking it into account. Download this: tssengine.com/downloads.html , make a random system from the File menu and then hit F8 and scale down the planets to real size. Then zoom in (mouse wheel) and they will be jumping around all over the place. This is for the exact same floating point issue as that which causes your white lines... it's an extremely frustrating issue for me as a developer but very nicely illustrates the point.
