It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.
No. You're wrong. Not having the right tools raises the cognitive load. You just think it's simpler because you are severely restricted in the complexity of the programs you can create with just your brain and the documentation.
IDEs expand the complexity of what you can build and make you more productive building programs of any size, because features like autocomplete and refactoring take thr cognitive burden off you.
In other words, you state that your way is the right way while my way is wrong.
Notice I did not state that my way is the right way for everyone? What makes you think yours is?
As long as you're working on a fairly standard type of project much of the taxing minutiae of programming is automated away by a good IDE that, unless you're working on a very small project, the time and effort saved is worth it.
In other words, that IDE which may assist you while you're building yet another CRUD project gets in the way when you're, say, developing a driver for a sensor on an IP camera based on a reverse-engineered example.
Sometimes, all the things the IDE lets you not think about is hugely more helpful than the additional cognitive load of modeling what the IDE itself is doing in your head.
Sometimes, having the thinnest possible layer between you and what you're running is hugely more helpful than the additional cognitive load of handling the things the IDE would've turn for you in wetware.
As ever, it's trade-offs all the way down.
As an aside, I feel the same about the unbridled growth of tooling around certain languages (Javascript being a prime example) and environments (Android comes to mind). Maybe it is just because of the way I started out with 8-bit assembly where a macro assembler was a luxury which could not entirely be trusted to do the right thing but I know I'm not the only one.