Keep in mind that each language has a learning curve. As you learn more languages, that curve becomes much easier to traverse. However, the goal is to Get Stuff Done. The most straightforward engineering tactic to accomplish that is to become highly skilled with a few choice tools, then use those tools to solve almost all of your problems. (Note: that's different than a "one tool for every problem" mindset. You can solve most problems with a small toolbox while still avoiding the trap of using an inappropriate tool for the job.)
I dabble in languages for fun, but find that I ultimately end up using the new techniques I learn in a few practical multiparadigm languages, e.g. OCaml, Lisp, and Python* . If you want to learn about types/powerful type systems, try Haskell or one of the MLs. If you want to see a brilliantly designed module system, look at the MLs. If you want to see well-designed syntactic sugar, look at Python and Lua (among others). If you want to understand OO better, look at Smalltalk. Etc. Spending a week (or weekend) now and then exploring the ideas and mindsets in unfamiliar languages, particularly those influential on what you do your real work in, can really expand your toolkit. (Also, read code.)
* Python is not fully multiparadigm, e.g. it's awkward for functional programming, but it's fairly flexible, and its giant standard library makes up for several weaknesses IMO.
Really knowing any one of the several languages I listed in the initial comment would probably be enough, and some approaches (e.g. Lua in C) could probably be learned relatively quickly. I suspect it would probably take much more time to learn to use C++ really well than OCaml or Lisp, though.
If you haven't yet, check out _The Unix Programming Environment_ and _The Practice of Programming_, both by Rob Pike and Brian Kernighan (K of K&R). They're concise, highly informative books about using the Unix toolset to their maximum potential. The former was written back when computers were slow and had little memory, the latter in from 1999 but very much in the same spirit. (It seems to include a lot of insights from developing Plan 9.)
Also, a dissenting opinion here: C's performance vs. higher level languages' development speed is not necessarily an either/or choice. Some languages (OCaml, the Chicken Scheme compiler, implementations of Common Lisp with type annotations or inference for optimizing, Haskell (under certain conditions...), others) can perform very favorably compared to C, but tend to be much, much easier to maintain and debug.
As a generalization, languages that let you pin down types are faster because they only need to determine casts once, at compile time, but if those decisions can be postponed until your program is already mostly worked out (or better still, automatically inferred and checked for internal consistency), you can keep the overall design flexible while you're experimenting with it. Win / win.
Also (as I note in a comment below), Python can perform quite well when the program is small amounts of Python tying together calls to its standard library, much of which (e.g. string processing) is written in heavily optimized C.
Alternately, you could embed Lua in your C and write the parts that don't need to be tuned (or the first draft of everything) in that.