How does the data account for variation in development 
  procedures (e.g. some projects use master as their 
  bleeding edge branch)?

That shouldn't matter. You should always be able to successfully check out, build, and pass all tests on master. Otherwise, how are people expected to get development done? If you aren't able to build and run tests because you need to be fixing something that someone else committed broken, it will be a lot harder to ever make real progress.

Even if it's "bleeding edge", master should always build and always pass at least the minimal "fast" test suite; some projects may have more thorough "full" test suites that take many hours to run, and requiring that those be run on every change would slow down development too much, but at the very least, the quick "sanity check" test suite should always pass before something can land on master.

Also consider that if its checked on a commit by commit basis that doesn't collapse merges in somehow, then you actually check every commit that was made during incremental work on a different branch. If you're doing TDD or any test first methodology, that's going to often mean you intentionally commit broken tests to fix them.

Also if its a commit by commit basis, the percentage of time comparison is completely invalid.

The author is talking about broken builds, not broken tests.

In this context they're synonymous. A broken build is defined by the tests failing.

The data is not really relevant for the reasons you state + failed build does not equal published artifacts. How long were the builds in that state? etc.