All of these metrics seem to be a poor substitute for building a team where you can trust your team to be honest about how they're progressing, where their blockers are and what technical challenges they see coming. If the way you're finding out a team member is stuck on something is the number of commits they've made in the last week then you aren't paying enough attention. More likely they're writing documentation, or researching, or just are working on a big change that they'll commit tomorrow or maybe they're simply babysitting the intern. Instead of actually knowing what you're team is working on, you've just created a new metric that doesn't really mean anything and is going to throw up false positives that you can spend your time chasing.
I mean, let's take impact. Can we measure the real Impact of a change? No. We're measuring a relatively bad proxy - connectedness. Is the change highly connected to all the other code. Is that something we want to encourage? Not really, if you're optimizing for impact you're creating a situation where your developers are going to write tightly coupled code. It's not good to create that artificial incentive. Okay, so maybe we want the opposite - low impact. Who exactly thinks aiming to be low impact is a good idea?
You could almost rephrase the subtitle as:
>Lines of code have almost no importance while other metrics of no importance are becoming more popular nowadays.