To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.
That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now.
That's why I like hobby projects - you get to choose problems that are interesting.
But i think programming is kind of unique in this respect too.
The tools sometimes let you approach a problem in a different way; sometimes "just getting on with it" means you're wasting a lot of time dealing with stuff that wouldn't be an issue in a better language.
To give you a concrete example, it's like when you do a CRUD application with a properly normalised database and then you need to add auth. And then you realise a transaction made at a certain date has messed up all later transactions. And then you realise you need to add an audit trail. And then you realise that needs to scale its services independently and you have to add micro-services. And then you realise you've got yourself into consistency issues because your services are sharing state through your db, etc etc.
Or you just implement CQRS and all those problems go away (yep you have different problems).
But i'm just saying that tooling matters, and picking the right tools can be worth hundreds of thousands of dollars.
I think the C / C++ argument is a strawman, it's not using all the features of a language that matters, it's picking the right ones.
Google and Amazon built businesses on Java, a tool that is as boring as a hammer. It was the architecture that mattered.
- Peter Norvig
But I really don't think it's about a language being boring vs not!
Pure functions are easier to reason about. So it makes sense that a language that encourages their use will be easier to reason about - which will help with maintainability.
Same goes for concurrency patterns - the closer they are to the language, the less room for mistakes.
I think the same for testing, but a lot of the time it's up a layer of the stack with a framework.
That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need.
JavaScript on the other hand....
On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.