Do polymorphism or conditionals promote better design?

Do not fear...

I guess your problem lies with familiarity, not technology. Familiarize yourself with C++ OOP.

C++ is an OOP language

Among its multiple paradigms, it has OOP features and is more than able to support comparison with most pure OO language.

Don't let the "C part inside C++" make you believe C++ can't deal with other paradigms. C++ can handle a lot of programming paradigms quite graciously. And among them, OOP C++ is the most mature of C++ paradigms after procedural paradigm (i.e. the aforementioned "C part").

Polymorphism is Ok for production

There is no "subtle bugs" or "not suitable for production code" thing. There are developers who remain set in their ways, and developers who'll learn how to use tools and use the best tools for each task.

switch and polymorphism are [almost] similar...

... But polymorphism removed most errors.

The difference is that you must handle the switches manually, whereas polymorphism is more natural, once you get used with inheritance method overriding.

With switches, you'll have to compare a type variable with different types, and handle the differences. With polymorphism, the variable itself knows how to behave. You only have to organize the variables in logical ways, and override the right methods.

But in the end, if you forget to handle a case in switch, the compiler won't tell you, whereas you'll be told if you derive from a class without overriding its pure virtual methods. Thus most switch-errors are avoided.

All in all, the two features are about making choices. But Polymorphism enable you to make more complex and in the same time more natural and thus easier choices.

Avoid using RTTI to find an object's type

RTTI is an interesting concept, and can be useful. But most of the time (i.e. 95% of the time), method overriding and inheritance will be more than enough, and

This is mainly to do with encapsulation of knowledge. Let's start with a really obvious example - toString(). This is Java, but easily transfers to C++. Suppose you want to print a human friendly version of an object for debugging purposes. You could do:

switch(obj.type): {
case 1: cout << "Type 1" << obj.foo <<...; break;   
case 2: cout << "Type 2" << ...

This would however clearly be silly. Why should one method somewhere know how to print everything. It will often be better for the object itself to know how to print itself, eg:

cout << object.toString();

That way the toString() can access member fields without needing casts. They can be tested independently. They can be changed easily.

You could argue however, that how an object prints shouldn't be associated with an object, it should be associated with the print method. In this case, another design pattern comes in helpful, which is the Visitor pattern, used to fake Double Dispatch. Describing it fully is too long for this answer, but you can read a good description here.

If you are using switch statements everywhere you run into the possibility that when upgrading you miss one place thats needs an update.