> I'm a recovering terminal junkie. I had a problem.
Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files.
But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script.
I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic.
I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated.
When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.