Either due to lack of knowledge, fear, or first-hand experience (getting burned) and saying "You know what, just because it's in the language, you don't have to use it."
Quoting Chris Rock: "You can drive a car with your feet, but that doesn't mean it's to be done!"
What's the C++ equivalent of driving a car with your feet?
I've never used and never will use goto. Apart from the standard "why goto is bad" debates, the most compelling reason is that it leads to debates.
For me it kind of depends on who the other coders on the project are and what the benefit of using the feature is.
The easiest way I find of tripping yourself up is making object ownership too complicated -- meaning that it's unclear who deletes what. In that sense -- holding onto pointers to member functions can sometimes be bad if it confuses people about how many referrers there are.
IOStreams (slightly embarrased) and especially stringstream I mostly do GUIs anyway and if I need to print something I think (s)prinft() is perfectly fine and a lot cleaner to read ( I do admit that << is safer)
I've never used longjmp in C++. Other than that, I've used almost everything (that I know about) at one time or another.
I rarely use these:
goto because it's usually emblematic of poor design on my part
RTTI because I've never really had a driving need for it(and it adds ineffiencies).
const_cast because constant values tend to stay constant in my code.
Things I would avoid, in no particular order:
Things I don't use, but not because I dislike them:
Multiple inheritance - Unless you only have one Class and the rest are abstract classes.
Multiple inheritance causes many many many headaches.
"Creative" overloading of standard operators can appear useful at first glance but can turn into a huge pain. Standard operators should keep doing what they would normally do.
Along those lines, implicit conversion operators are often a really bad idea when it comes to maintenance. Maybe your WidgetFrobber class can sensibly be turned into a string or an int*, but that doesn't mean it should be implicitly convertible. Provide a ToString() or a ToPointer() method if you need to do that - don't add an operator int*().
This is a bit different than a lot of the other answers, and in some sense it's not exactly a feature, but I avoid manual resource management. Manually freeing memory rather than using auto_ptr or shared_ptr, or manually releasing COM interfaces rather than using CComPtr. Sure, you can manage resources yourself, but that doesn't mean you should.
You could call it the "C++ can be written just like C" feature. Bad news.
STL algorithms and function objects. While they're a cool idea, and certainly work effectively, it almost always seems to work out that I can do the same thing with a loop with much less code.
I don't think there's any feature that I would deliberately avoid. I think it's more about choosing which features to use with care, making sure that they work together to towards a good, clean solution. Even the best features of C++ can be abused.
There are features that I've never used, such as RTTI. That's doesn't mean I would never use it. It just means that, so far, it has not been necessary for me to use it.
EDIT: I don't use exception specifications. I thought they are going to be deprecated in C++0x.
Template's are great, when used judiciously, but I think template meta programming is the spawn of the devil.
I don't avoid anything that's a standard feature. There are some (like macros and arrays) that I won't frequently use, but I use every part of the language, including exception specifications and locales, which are both (in my opinion) vastly underused. Exception specifications are not as powerful as they are in Java, but they can cause a call to a function of your choice, which can do something useful like print a backtrace at the point of the violation.
I also try to use Boost whenever possible, since I consider it to be the standard library's little brother.
Actually, there is one feature I never use, and that's export. But were it implemented to a useful degree in compilers, I probably would. Unfortunately, it isn't, so I won't use it.
EDIT: Alright, I won't use some legacy C library features like longjmp or varargs either. But they don't tend to work that well in C++ anyway.
Lately I've been learning to use polymorphism to avoid switch. In many places a huge switch statement used to determine what derived class an object is can be replaced with a virtual function call.
There is an excellent list of frequently questioned answers that has a detailed enumeration of all the things in C++ that you probably shouldn't use.
Oddly, enough.... pointers.
With std::vector<> and std::string, there's really little need for them. The few that are left are squirreled away in a class, with a new in the ctor and the delete in the dtor.
I pretty much use everything else mostly via boost and STL :). I've needed setjmp/longjmp to implement resume in test code to check exactly how many SIGABRT/SIGSEGV/SIGBUS are received. I personally never needed goto and fall through switches but I've seen nice code that use them and certain wouldn't avoid them when needed.
RTTI, because it is never really the right design for me
virtual base classes. Has anybody used this for more than a sample in a programming tutorial?
Exception specifications. They don't work the right way.
On the other side, I do use inline assembler, goto, multiple inheritance when appropriate.
I never tried writing my own memory allocator for STL container, probably I don't belive I can beet the guys that wrote my STL implementation.
Second thing that's on my list is writing my own STL container so all iterators / algorithms from STL works with it.
Avoid exception specification which does not work as you may expect. Herb Sutter explains you why in the article "A Pragmatic Look at Exception Specifications"
I avoid anything I'm not good enough in to keep my feet bulletproof. The top of the list would be: templates meta programming as a whole, multiple inheritance and polymorhism. Yes, each of this features may save me a bit of time while implementing somethins in C++ code, but I need to spend a lot of time to study them in the first place. I do learn new stuff little by little, so maybe I won't avoid some of this features in a future. For now I can get my work done with the skills I allready have, and I'm not getting paid for toying with languages cool stuff.
Speaking from the context of a C programmer, who at times has been thrust into the postion of trying to understand others c++ code, here are some things I would recommend not doing:
yeah it may inhibit object orientation, but my experience is that these features encourage excess unneeded object orientation which in turn makes for very difficult to understand code.
I avoid the export keyword because of its (non-existent) implementation of most compilers.