But the article further says: "Filesystems are not required to know about or report holes; SEEK_HOLE is an optimization, not a means for producing a 100% accurate map of every range of zeroes in the file."
And the man page you linked to says: "A 'hole' is defined as a contiguous range of bytes in a file, all having the value of zero, but not all zeros in a file are guaranteed to be represented as holes returned with SEEK_HOLE."
So, it would seem that the "10101010" case would be covered by skipping (it's clearly not a hole). Even if the filesystem were maniacal and reported each 0 as a hole (ie. lying) everything should still work, it just means backup software could be made to do an insane amount of work to faithfully "reproduce" such bogus holes; they could protect against that. Might be fun to add this behavior to a bogo-filesystem for testing.