I'm going to tell you a story.
Up until about May 30th 1999, John Carmack did not know that scissor test was not enabled by default in OpenGL.
The next thing is sort of funny. I had been suspecting that a lot of the OpenGL drivers were clearing the entire depth buffer for each of the 3D icons on the status bar, instead of limiting it to the scissor region. I added code to the g200 driver to explicitly crop the clear region in the driver, but it never got executed. A little more investigation showed that I had been making an improper assumption for years -- scissor is not enabled by default. Doh.
Finding this out came to him totally by accident, in the context of doing something else, and gave his code a fairly nice performance increase (given that he works in an area where performance is hugely important, this is worth noting):
Now I know that I was just being an idiot about that for the last three years... With scissor enabled, most of the cards got a few percent faster.
It's also worth noting his self-awareness here: "I was just being an idiot about that for the last three years".
Now, if he had read the documentation ("The test is initially disabled"), he would have been aware that scissor test was disabled by default and would not have made that mistake.
Is this a case where reading documentation would have made John Carmack a bad programmer? Is this a case where not reading documentation made John Carmack a better programmer? I don't think I need to answer those questions.
As for intellisense, it's important to realize that intellisense is a productivity tool, designed to save your time. You type "." or "->" and up pops a list of members, you type the first few characters of the one you want, and hey-presto! That's your precious time it's saved, it may have also saved you breaking a build owing to that supid typo you made because you hadn't had your coffee yet, and you've now got more time to get on with doing productive stuff instead of just grinding out code.
Intellisense is not designed as a crutch for bad programmers, it's an example of what Fred Brooks calls a "Sharp Tool".
By the same logic that one may dismiss intellisense, one comes to the obvious end conclusion that any tool designed to increase programmer productivity is also something that may make one a bad programmer. That's a dangerous line of thinking because next thing you'll be rejecting compilers and debuggers.
When I was back in college last century, one of my lecturers told us that "the best programmers are lazy". That's very tongue-in-cheek, and what he meant was that the best programmers find ways to maximize their productive time and minimize time spent doing donkey work. I still think that's good advice today.