The biggest problem with a programming book is how to use it. The content in this book is rich, deep, and helpful. But I have to admit I was dubious about getting this book because I could see no solid case for it improving my programming in the laid back format of the previous "50 Specific Ways..." books. And what I found was consistent with my original impressions.
The problem with teaching people to use the STL better is that they have to actually have experience using the STL. I don't just mean experience in a class, I mean real-world programming experience (although such a world is undoubtedly very removed from reality). Real world experience with the STL where this book will actually help you, I believe, is so far removed from most software development activities that this book will haunt you you more than help you.
The "50 Specific Ways..." series is actually really useful in that it highlights problems you are likely to encounter when using the environment covered by the subject in the most common ways. The problem is that people who actually develop code with the STL code (i.e. really incorporate it) are probably a lot fewer than instructors would like to claim. I have relatively wide experience in programming with C++ including stand-alone simple stuff, C++ in support of visual studio, C++ for DLL applications, C++ as driver code (perhaps C would be better?), and C++ as part of a roughly 1000 person collaboration developing something like 100k new lines of code every week. In my experience none of the more casual programmers - even in the 1000 person collaboration - had any clue of the details that Scott Meyers touches on in this book.
So the biggest dilemma is how to use this book. That actually is an easy question because the sections are well-written and the material is thorough. First read it quickly. Then use it as a desk reference while reading, editing, and writing code that is based on the STL. Start by using the sections where Meyers explains which containers are good for what specific purposes. Then, if your particular application is discussed in the book, re-read that section again realy quick before writing code. Then, when you encounter compiler complaints, use the book to help you figure out what is wrong. For the most part the cross-referencing of compiler errors is pretty good, and there is a section that helps diagnose the meaning behind compiler complaints that span several 1000 characters.
As an example, Meyers discusses why you should use &V[0] to get a pointer to the start of a vector (see item 16). Now, when I was working with the 1000 person collaboration, this type of code showed up all the time. My impression was that this was actually bad practice, and that they should really have been using V.begin(). However, this is not good practice, and Meyers explains why. He also explains the reason you need to use &V[0], and why you need to check V.empty() before using it.