Определенно, все зависит от языка программирования, так как в каждом реализация поддержки классов и объектов выполнена по-разному.
Что касается C++, то практически нет. Я работаю над приложениями, в которых активно используются не только классы и объекты, но и наследование с интерфейсами и "деревьями" порой в несколько базовых классов (в этом нет ничего необычного). Снижения производительности быть не может, поскольку, если смотреть на ассемблер из-под компилятора, которым я активно занимаюсь в том числе, можно сказать нет никакой дополнительной "нагрузки" (если у вас современный процессор от 3GHz, ниже - это уже мобильная тема). Нынешние компиляторы работают очень добросовестно, поскольку уж очень много людей над ними работают и постоянно вносят исправления не первые 10 лет. Многие, кстати, считают, что виртуальные таблицы (vtable) в плюсах нужно избегать, но даже они не замедляют программу, в том числе, в коде под компьютерне игры, это тоже факт из опыта. Возможно, для каких-то явно дьявольских оптимизаций имеет смысл отказаться от наследования, но не от объектов классов как таковых (слабо себе представляю это).
Что касается python, моего второго favorite языка в продакшене, все несколько сложнее. В одном из приложений используются классы с более чем 5 базовыми классами, каждый из которых так же имеет суперклассы. Думаю, что пока к скорости работы нареканий нет, хотя все упирается в производительность базы данных (кстати, вот тоже пример реальной проблемы, а не попытка искать минусы ООП).
Только недавно в этой программе сделан рефакторинг, после чего такое появилось, раньше был чуть ли не один большой скрипт с одной функцией в 1700 строк. Я мельком замерял память на первых версиях кода и после рефакторинга. Памяти стало использоваться немного больше. Примерно 19 мб против 25 мб после. Не нужно забывать, что python и похожие на него языки заведомо имеют очень низкую производительность по сравнению с низкоуровневыми языками.
Но то было серверное приложение, без GUI. А что касается C++&Qt под windows, да ровно как и WPF и WinForms, то эти решения страдают от избыточного расхода памяти. В основном, проблема не в них, а в том, что большую часть функций, которые они реализуют, программист так и не использует (описать, почему именно это плохо, будет очень длинно). Если с C++ такие случаи менее "вредны" - из-за оптимизаций компилятора, с более высокоуровневыми языками все сложнее. Там компилятор не может просто "выкинуть" код, по крайней мере в C# и Java. Но это опять же, проблема сомнительная, если вы решите воспользоваться этими решениями, иначе - не пользуйтесь, есть альтернативы.
Что касается Java и языков Microsoft.Net, таких как C#, вы никуда не денетесь от ООП, так как "внеклассовый" код на них писать нельзя впринципе. Ну а слишком глубокое наследование там и не получиться вроде.
Есть еще один аспект вопроса, который затрагивается, в случае с подобными языками (типа Java, .Net и Go). А именно, garbage collection; сборщик мусора может быть реализован по-разному. Я мягко говоря пока не сильно искушен Go и Java, но надо сказать, что любой GC вполне может иметь баги или пожирать слишком много процессорного времени ИЛИ оперативной памяти. Но с годами ситуация меняется, даже Microsoft однажды исправили эту проблему в C#. Если значительное улучшение можно назвать исправлением.
GC есть у любого языка, который автоматически управляет памятью. У менее безопасных языков, вроде C++, есть проблема утечки памяти (memory leak). Утечкой памяти называется баг, из-за которого программа выделяет память под объекты, а затем не освобождает её, когда объект более не используется. Опыт показывает, что такие утечки могут существовать много лет даже в очень популярных open-source приложениях. Причиной их возникновения является невнимательность, и как раз, избыточное пользование объектами/наследованием, пулами и прочие запутывания программы самоей в себе. Но это не стоит отказа от ООП, это челлендж.