I know productivity superstars, but if you catch them on the wrong day or at the wrong time, they look like lazy bums.
I've encountered a particularly nasty variation of this since Agile became a Thing, where anyone who isn't writing code or running tests or showing up in the commit logs every few minutes obviously isn't working. The idea that it might be better to step back for an hour, or a day, or even a month, to think things through properly and maybe do some throwaway prototyping before you start pushing code to production, doesn't even seem to be accepted as credible any more in some quarters.
People don't recognize it as such because the LOC -- lines of code -- has an added time dimension now and a different name. In Agile / Scrum it's K-(issue/day) where issues take the place of raw lines and the metric is applied per unit of sprint duration.
But same idea, and same fallacy. It results in gobs of ugly Rube Goldberg machine code that's slow for fundamental O(crap) reasons and bug-ridden.
An org that calls what it does "agile" or "scrum" and then proceeds to accumulate technical debt like the Titanic taking on water is lying to itself about what it's doing. Piling up technical debt is a textbook Agile(flavor) failure, full stop.
What sounds like happened in the case(s) you describe is that someone with dev management preconceptions wore "Agile" like a wolf in sheep's clothing and proceeded to dole out the same old ad-hoc nonsense. Nonsense as in being "efficient" (high KLOCs/metrics, butts in seats, long hours, etc.) and not caring about being "effective" (working on the right problem vs a problem, necessary understanding of the company and customer needs, working smarter vs. simply harder, etc.).
I've seen this attitude a number of times, e.g. in program managers with history in big, established s/w companies. They learned a certain way of working, but then talk "Agile" as the trendy hire-word. Unfortunately, some of these folks never gained understanding of the tools that Agile brings to the table, and when/how to apply (or not apply) them to a situation.
I had a manager who believed that such metrics were the only true measure of performance. This same manager also believed that CUDA on a VM (which is itself on a server hosting numerous other VMs, and the bare-bones minimum graphics card--so no support for virtualized usage of CUDA) was a good suggestion for improving performance, that running a debugger on a specially compiled Apache webserver in the production environment would be a great way to troubleshoot performance issues, and that having an 8-12 week sprint/"rolling release cycle" was "Agile" as long as we called it that.
So, yeah, some people just don't get it. At all. And in my experience management is definitely a place where one is more likely to find such people.