When there are so many other projections to chose from, why is it that today the Mercator projection is still such a widely recognized image used to represent the globe? The answer may be simply convention or habit. The inertia of habit is a powerful force.
The main reason Mercator's projection became so popular was because of its navigational usefulness; in his map, straight lines represent lines of constant compass bearing. However, in manipulating the map to ensure this feature, the sizes of countries become hugely distorted. In particular, the southern hemisphere appears much smaller than it is in reality.
Map projections have become a popular new-journalism meme. With a quick article, you can recap centuries of cartographic history and open peoples eyes to a variety of unusual ways to shape the world. The hook, then, writes itself: the projection we use every day is _flawed, wrong, and maybe even racist._
Since the rationale for Mercator's dominance over web maps is part technical and part cartographic and hasn't been packaged into a readable bite, the "why" is often left out. So, let's explore.
Pardon the sudden dives into map technology and so on.
Let's start at the bottom.
How map tiles work explains why map projections are a winner-takes-all game.
Web maps are composed of 'tiles': image files that are typically 256 by 256 pixel squares. These tiles are 'stitched' together by software, so that there's no space between adjacent tiles and what you see is a continuous map of the world. As you zoom and pan around a map, different tiles are loaded and assembled into the map you see.
Then, when multiple maps are combined - like when you show a heatmap of runs on top of a Google Maps layer - these tiles are simply displayed one on top of the other. Since the layers 'line up' with the same projection, the result makes it look like there's one image.
Why does this matter? The conversion of a map into tiles means that you're making a decision about the map's projection ahead of time. So, for instance, Google provides tiles in the Web Mercator projection. These tiles are rendered into images that represent parts of the world: the world is split up into chunks and those chunks are rendered in one specific projection, and these tiles cannot be adapted to any other projection, or, more importantly mixed with any other projection*
The most important fact of projections is as follows, from Wikipedia.
Carl Friedrich Gauss's Theorema Egregium proved that a sphere's surface cannot be represented on a plane without distortion
Through this lens, every choice is a compromise. Gall-Peters is just a slightly different compromise than Mercator: you can have accuracy of areas if you sacrifice direction or conformality, and vice-versa.
Importantly, Mercator wins in conformality, which is the most important attribute of worldwide zoomable maps.
The first launch of Maps actually did not use Mercator, and streets in high latitude places like Stockholm did not meet at right angles on the map the way they do in reality. While this distorts a 'zoomed-out view' of the map, it allows close-ups (street level) to appear more like reality. - Google
A common rebuttal to the projection problem is that vector data will save the day. For low levels of detail, this is already true: libraries like d3 can reproject data into many projections on the fly.
However, the gap between country-level visualizations and actual street maps is large. Creating street maps means dealing with label algorithms, fast simplification algorithms, and lots more: the level of difficulty explains why Google's MapsGL has been the only vector street map in production, and why vector street maps skipped over Canvas and SVG straight to WebGL as their technology.
What does this have to do with projections? Well: as it turns out, to create vector street maps that actually work, and have similar performance to the tiled raster maps, you need to make two compromises.
First: vector maps aren't the end of tiles: they're just the beginning of vector tiles. The pipeline of rendering tiles actually doesn't change significantly beyond the end product: instead of Mapnik producing a PNG file, it creates Protocol Buffers.
The clever reader says: yes, they're tiles, but you can reproject those tiles, right? The answer is sort of but not really.
Because, second: vector tiles are simplified to the projection. That means that the simplification algorithm that is run on vector tiles throws away details on shapes that won't be visible on-screen. So, it has the assumption of projection X, and if a certain street label won't be visible when the map is displayed in that projection, it doesn't encode it in the data. If you reproject the tile to Y, and the street label becomes visible, you have an empty spot.
- The only exception to this rule is MapProxy, which is able to reproject tiles - but this is both rare and imperfect. The reprojected tiles show artifacts and often will have warped labels as a result.