From the spec:
4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Why do some GitHub repos have 0.x.y releases if version 1.0.0 is the first public API release per SemVer2?
Because the maintainers do not wish to give the impression that their code/API's are stable or ready for production. They are reserving the right to remove or modify any of their API's without warning, for any reason they deem appropriate.
THOUGHT: Is a release in the 0.x.y phase usable code that just doesn't have API documentation yet? Is that what that means?
It means exactly what the spec says it means. If that's not clear enough, then you'd have to ask each of those repo's maintainers, what they think it means. In general, you should always treat prerelease versions as dangerous, unreliable, and subject to change without notice. Do not deploy any prerelease version into production, without thorough testing prior to deployment.
e.g. Tensorflow has releases on GitHub starting at 0.5.0. Is this acceptable per semantic versioning, or are they simply not following semver and using something else?
You should ask them if they are following SemVer. Any random version triple may have the appearance of a SemVer string, but that does not mean the publisher is adhering to SemVer. If they say they are SemVer and the first publicly available version is 0.5.0, that's perfectly acceptable. It is common practice to start at 0.1.0 for prerelease of the first feature(s), but there is no rule that requires it. There is also no requirement that older, possibly less stable versions, be left in public view. Nor is there a requirement for continuity of the version history. Any random version may be removed from public view for any reason the publisher deems sufficient cause to remove them.
When a publisher issues their first major version, they are saying "here's an API that we will not break". The SemVer spec allows them to fix bugs in their code and documentation with patch level version bumps, and add non-breaking features with minor level version bumps. The spec does not say how big those bumps should be.
