I have no idea whether it correlates with "very smart" in any particular way, and suspect that it probably doesn't, but I have definitely observed significant differences in preference when it comes to the use of extralinguistic tools. It's easy to see how there are some people better suited to early adoption of new languages than others, because they are comfortable with and may actually prefer a minimal-tooling environment, while others will find it so unbearably primitive that they won't be able to get anything done.

I've had coworkers who believed anything that can be automated should be, and therefore one should learn and use all available tools. In this view, anyone failing to take advantage of all possible automation is wasting their time on grunt work and therefore being less productive than they could. One guy at my last job was notorious for his incredibly long and frequently misspelled identifiers; I could not understand how he was failing to notice these problems until I realized that he literally never typed out a full identifier more than once, and typically generated as many bytes of source code via intellisense as he did by typing.

I am out on the opposite end of the spectrum; when I'm coding I don't want to think about tools at all, and a tool had better be absolutely spot-on perfect or its rough edges will waste more of my time by distracting and irritating me than its features will save by automating something I would otherwise have had to do with my brain. I sometimes use IDEs depending on the project, but I always disable code indexing / completion, because the little timing hiccups you get as the tool does its thing break my flow and irritate me. Instead, I put more time into making consistent names and simple APIs so there is less to remember, and do a bit of extra grepping when I can't recall what I need. For me this feels easy and natural; for other people it seems like going the hard way, and they don't understand why I won't let the machine help.

These differences extend all up and down the tool chain; some people love their sophisticated debuggers and write all kinds of complex scripts that produce interesting results, while I tend to just throw in a lot of printfs and debug by reading logs. Not to say I won't use a debugger when it's available - just that I know the log approach will always work, and it can be less work to fall back on something simple that I don't have to think about rather than taking the time to remember where all the debugger's knobs and switches are. On the flip side, I will make heavy use of all available language tools for abstraction and code simplification - lambdas, namespaces, interfaces, whatever's handy, my goal is to build every interface, no matter how minor or internal, in such a way that it's difficult to use it improperly. This has irritated people I've worked with who are happy with simple boilerplate because they rely on automated refactoring tools; to them, these esoteric abstractions were aggravating because it left them struggling to see the forest for all the unfamiliar trees.

Some of this may be a function of experience, particularly experience with low-level environments. I've written plenty of debugging, logging, grepping, and reporting tools over the years, so I know I can always just bang together what I need in the moment, and the prospective payback from learning some existing do-it-all tool feels correspondingly reduced. But is this a smarts thing? I am not so sure - I mean, I do think I'm pretty smart, but it could just be preference; I really like digging into the foundations of things and have therefore invested a lot of time learning how to work in those environments. Someone who actually prefers to live at a higher abstraction level might well be wasting their time by thinking about this sort of thing, and while that's not my bag I certainly wouldn't argue that high-level work is unnecessary or of lesser importance.

Some of it may also be a function of age. I've seen so many tools come and go that it has come to feel like a waste of time to learn one deeply until it has become stable and ubiquitous enough that I can reasonably expect the time I invest in it to pay back over at least 5-10 more years. If it doesn't meet that threshold then why bother? There will just be something else coming along later. I'll learn it if I need to use it, but because of the above-described confidence that I can get the job done regardless of tooling, I'm less likely to hit the bar for "need to use it".

The weakness of the heavy-tooling approach is that tools always have flaws and blind spots, and one can get stuck thinking through the tool's mindset and have trouble when there's a problem it doesn't solve particularly well. But the weakness of the light-tooling approach is that tools shape mental models, and mental models shape language, and software development is really more about communication between humans than it is about communication with machines; if you don't adopt the mental frameworks your coworkers are using it may be more difficult to interact with the systems they are building.

(also, a moment of brag: one of my proudest debugging feats was when I wrote a bootloader for a brand new embedded architecture using no feedback but a single blinking LED. There was no stack trace, not even a serial line for a printf log, because none of the drivers had loaded yet.)