I do not agree that iterators and the STL should be beelined for in an academically-minded C++ course. I'd far rather have students focus on the ability to build and compare different collection classes of their own, and understand the tradeoffs of whatever class they might encounter.
Aim for producing graduates who have enough grounding to look at the function prototypes in the STL docs and go "oh this is one of those types of approaches". Then they can have an equal confidence if they dig into some the big name codebases that they heard of which "use C++" but which don't use STL... like how Firefox foregoes
std::string and defines its own (nsAString_Internal) hierarchy. Or nearly every Qt program out there, etc.
In the real world, cross-cutting concerns often preclude projects from using the STL. That can be issues like threading on embedded systems, implicit sharing, or Unicode. It's precisely the power of C++ to attack these problems with custom solutions that has kept the language relevant when going up against its nimbler interpreted competition. People who live and breathe C++, even for purposes best suited for shell scripting, miss that point.
Since most of the other languages people are exposed to these days are interpreted, a real understanding of "compile-time" vs "run-time" is essential. Not just in terms of performance but in terms of globally assuring certain types of errors don't exist. Template syntax can get ugly, but all the more reason to show why anyone bothers with it.
Throw Valgrind in there and get them used to understanding what's happening to their memory from day one, and how automatic memory management can help. Let them write their own auto_ptr and then give them situations where it will flop in a simple collection. Have them write essays about why and re-derive unique_ptr and shared_ptr.
Bjarne Stroustrup makes some great points in his C++ teaching (which I often link to). But he's usually making arguments to hardened C programmers that if they think their C programs are faster than comparable STL-based C++, then the programs are probably only faster because they are incorrect. This takes the foregone conclusion that your problem required C-level performance in the first place, and no programmer of this generation should be assuming that.
In summary: I'm not suggesting "C with classes". I'm suggesting "Grasping the design tradeoffs in C++ software design [leveraging tools like inheritance, RAII, templates and overloading]" Too much STL emphasis up-front will just lead to a bunch of angry Java-converts-in-training who can't cut their teeth on showcase C++ projects.