They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
A manager has a duty to "catch" (as you put it) underperformers, to help them improve.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
The engineer did not choose to represent themselves in weird daily show-and-tell meetings. The commit history is there regardless. You could just look at that.
