This reads to me like "the darn developers are spending too much time not laser-focused on business impact and keep bikeshedding and doing make-work!"
It's impossible to tell if this is what's happening though. It can really go either way.
I've seen orgs where the perf-review meat grinder is driven so tight that engineers are essentially punished/PIPd for doing things that NEED to happen even if they aren't sexy business impact. Like upgrading library versions (not all of them, just the core/most important ones!) so you don't wake up one day and realize you're on a 6 year old version of a core library/framework. Even remediating incidents was treated as "not impactful work". This resulted in the expected shitstorm and teams were literally churning employees because oncall was so bad and just doing anything was so awful, and it took a staff engineer's guile just to get an otherwise-relatively-simple project over the line because you had to be a ninja just to navigate the awful existing mess of 10 years' worth of laser-focus on business impact.
And I've seen orgs where the engineers run rampant, doing random side-quests constantly, junior engineers run amok over-architecting every project with all of the skills their CS degrees gave them, senior engineers make magnum opuses of medium-sized projects, and principal engineers pontificate and aid and abet any and all architecture-astronauting that anyone else in the org does. And naturally none of it was done in any way shape or form in coordination with product.
And naturally there's everything in between. So whether they have a healthy amount of focus on non-sexy work and wish they were neglecting it more to reap shorter-term product-focused gains, or they have too much bikeshedding and they want to be more product-focused, it is difficult to say.
(Naturally the cynic in me says it is probably the former, though...)