Too bad there aren’t more general docs for the library.
I still don’t quite understand the benefit of using a single number instead of a pair of numbers for describing a cell in a two-dimensional space. Seems like a pair of 32-bit fixed point numbers would be just as descriptive as a single double-precision float along the hilbert curve.
The way they project the sphere onto a cube also leads to cell shapes that aren’t especially relevant to typical human purposes, whereas there are many shapes on a map which align with the latitude/longitude grid.
The most famous example I know is, of course, XKCD's Map of the Internet:
The checking of containment, to verify if a cell is contained in another cell, all you just have to do is to do a prefix comparison. These operations are really fast and they are possible only due to the Hilbert Curve enumeration and the hierarchical decomposition method used.
My take is that they should allow height to be coded in too.
As a result one of the first things I asked them was "where are the corners?" and they confirmed my suspicions that they have "tilted" the cube slightly (the vertical edges are not parallel to meridians at the equator) and that a very rough approximate location for two of the corners is one is roughly in the great Australian bight on the South Australian coast line, and another one is roughly in the sea of Okhotsk between Japan and the far eastern half of Siberian region of Russia.
TL;DR. Yes, yes they do try to put the vertices in areas where their distortion will be least noticed.
The lookup table it references is generated up here:
(peano not hilbert but very similar idea)
The links the authors provide to learn more about the HSFC probably discuss it too!
 For the 2D version, split divide the quadrants with the center x and y axis. For the 1D version, just break it into four equal length pieces.
What I want to tell is that this library is not (yet according to some googling) migrated to the new platform even when it is from people from Google.