The claim is - at best - naive.
SLOC isn't exactly a reliable metric for anything useful, except perhaps comparing the size of two or more projects. Furthermore there are two distinct types of SLOC, physical LOC and logical LOC, and those might differ significantly. Consider this example, from Wikipedia:
for (i = 0; i < 100; i += 1) printf("hello");
Here we have one physical LOC, but two logical ones (
printf statements). But we could of course write the example as:
for (i = 0; i < 100; i += 1)
Which would give us two physical and two logical LOCs. I think it's clear that any "bug per loc" measurement that would depend on physical LOCs would be tainted by programming style, thus our measurement would be largely useless.
If, on the other hand, we went with logical LOCs then our measurement would heavily depend on the language's syntactic idiosyncrasies. Although the resulting metric might be a bit useful when comparing projects written in the same language, it would be fairly useless for projects written in different languages.
One possible source for the claim is Les Hatton's Software failures-follies and fallacies:
We can conclude that programming language choice is at best weakly related to reliability.
Later on, the paper mentions similar defect densities for C and C++:
In a recent study comparing two similar systems of similar size, (around 50,000 lines each), one in C and one in object-designed C++, the resulting defect densities were shown to be around the same at 2.4 and 2.9 per 1000 lines respectively.
This, however, doesn't mean that "bug per LOC" is constant across programming languages, or that it would be significant if it was.