I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform.

This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is.

For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category).

Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?