I'm not one of them. I tend to try to write programs that are simple to implement and understand. I don't like to use the very obscure features of Perl unless it's absolutely necessary. I'd rather spend time up front designing things so basic language features can be used, and it doesn't take a lot of time (especially for someone who's maintaining my code while I'm not available) to understand how it works.
I get the feeling, based on interviews I've read about, and some I've had, that there are more software engineers who dwell on these details now than when I first entered the field. Moreover, because managers tend to favor the opinions of the software engineers over their own impressions, if the engineers interview candidates based on these details, otherwise competent people might be passed up.
In The Mythical Man-Month, the individual who spends a lot of time on the details of languages is identified as the "language lawyer." (Why do I remember this?) This is a specialization of a programming team that is built on the "surgical model." This seems reasonable to me; it helps to have someone who knows some of the finer points of a programming language because there may be better ways of doing something. But does every team member need to be a language lawyer?