> Если держать себя в руках, то на ООП на С++ получится лучше,
> т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от
> обилия возможностей у многих в руках начинает свербить.

1) то, что ты называешь возможностями я называю ограничениями.
2) Пример очень печального ограничения, вводимого ПРИНУДИТЕЛЬНЫМ НАЛИЧИЕМ vptr/vtable - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI после расширения. Этот вопрос у С++ников как правило вообще не поднимается, потому, что чтобы достугнуть хоть какой-то совместимости API между версиями нужно уже обратиться к Си: вынести конструктор класса в отдельную сишную функцию, а сам класс описать как набор виртуальных ф-ий.

Под совместимостью АПИ я подразумеваю, что можно подложить либу новой версии к старой версии программы, после добавления новых функций.

т.е. кошерный API на си - это:

typedef struct obj_s obj;
obj * new_obj(void); // construct
void delete_obj(obj*); // destruct

int method1(obj*, int);
void method2(obj*);

При таком оформлении АПИ можно добавить новый метод с сохранением работы новой либы на старой версии программы (которая была скомпилена ещё со старым .h и стоит где-то на объекте. Скажем, на газовой станции.).
На С++ приходится исхищряться:

extern "C" {
obj * new_obj(void);
void delete_obj(obj*);
}

class obj {
virtual method1(int) = 0;
virtual method2() = 0;
};

Как видишь, уже начинается костылизация. Но основная печаль не в этом.
Если от класса obj что-то унаследуется в API (в сишном случае можно просто применить уже имеющиеся методы к наследуемому классу), то ничего ты уже в obj не добавишь.
Поэтому самые крутые С++сники просто забивают на совместимость версий, и хреначат описание всего класса прямо в хедер. Техподдержка от этого страдает.