It's one of those things where you get excited that there's something so accurate, but also a little fearful of how management could use it to incent badly written code.
That depends on the management. There can be an incentive for comment/code ratio, with tooling to extract and measure metrics on the comments to make sure they're not trivial. Another possible incentive would be based on metrics of diffs, using a ratio of features added or bugs fixed against the number of lines added, where a smaller number of lines is better.
Why would you incentivise comments over self documenting code that clearly expresses the intent? Comments get out of date and aren't subject to static analysis.
There are plenty of techniques that let you write code that reads like an English specification rather than details of how it is implemented.
If you find yourself needing to write a comment, it's always good to think how you could re-write the code to say the same thing as the comment.
I see self-documenting code as another type of comment, not a replacement. The comments describe what the code is supposed to be doing, what business problem it addresses, etc, while the code documents how the code does what it does. Your comments shouldn't get out of date unless the purpose of the code changes. If it's just the implementation that changes, the comments should still apply.
In my experience, the density of comments is inversely proportional to the extent to which they help the reader to understand how the code works.
On my current project, it also tends to be inversely proportional to maintainability. Never send slashes and asterisks to do a function declaration's job.
