There have been many uses of hex grids and maps for a while, such as Civilization V, and this awesome hex grid resource from a gaming company: https://www.redblobgames.com/grids/hexagons/

Others have pointed out various indexing systems that NASA uses that support hexagons, as well. H3's advantages over the others is, in my opinion, that we tried to marry as much of the awesome S2 library into a hexagonal grid (short 64-bit addresses for all hexagons at all resolutions, a parent-child tree with no shared parents, minimized area distortion, and a pretty simple API with some built-in utilities, like geofence polyfill, hexagon compaction, GeoJSON output, etc), where the hexagonal properties give you the other advantages I outlined over S2.

To be perfectly fair, there are some things that S2 will still do better than H3, most notably that the area coverage of a parent perfectly matches all of its children, where that's not the case with H3, though we minimized it as well as I think is possible.

Kevin Sahr (whom others have cited in here) worked with us on this library and came up with the parent-child orientation and scaling, and implemented the original version of the code.

Hexagonal pixel grids have been used for decades by many different people for various GIS/mapping applications. If you do a google scholar search you will find hundreds of relevant papers. They’re still uncommon compared to square grids, because they are less convenient in several ways, and less familiar – every part of our culture (textiles, architecture and construction, mechanical engineering, urban planning, writing and books, furniture, visual art, toys, cartography, circuit boards, computer displays, abstract mathematics, ...) is deeply rooted in rectangular grids.

Like most tools/conventions, there are trade-offs involved.