I think you're reading that the incorrect way, though it's hard to say. This is my take on it

Dev: I get paid for writing features. I can write new features faster in {insert slow interpreted language here}.

Also if the company is of any size, whatever they write has to fit in the rest of their CI/CD stack and pass whatever kind of code review the company does or doesn't implement. So yea it's easy to say devs suck (and they do), but without looking at the entire process they are involved in it can be very hard to qualify why they suck and where the suckage comes from.

The slowness of interpreted languages is frequently not the main culprit for slow performance though. Most load times in web apps I've worked on usually were spent doing inefficient or unnecessary DB queries or API requests.

Almost every single time I've had to deal with something being slow in the Python web app I work on, it's been a bad query, or bad ORM usage spawning thousands of additional queries to pull in relations.

I've seen a couple out-of-memory deaths (mostly non-paginated db queries, but compounded with the inefficiency of py2), and occasionally an accidentally quadratic loop (which would be faster in C, but usually can just be made fast in Python with more thoughtful code), but it's almost always the DB—oops, I need to add an index, oops I did a cross join, oops, I'm spawning additional 10 queries for each row returned. The time spent in Python on a slow endpoint is usually negligible.

This is the claim but it isn't necessarily true as often as it is claimed. If it was how would Stack overflow back in the .NET framework days have managed on I think 2 web servers plus a failover on the massive amount of traffic they do while also being responsive. There's 0 chance a python/ruby/etc web app could have done the same thing. And to think they could theoretically use less CPU and RAM on the same workload now running in .NET 6 which is dramatically more efficient than 4.x Framework.