К тому, что если вы захотите кастомизацию, которую конструктор не поддерживает, вам выкатят счёт, в разы превышающий нормальную разработку, или вовсе откажут.
Как выше отметили - это всё для прототипов или для не слишком требовательных заказчиков.

На самом деле зависит от того, какое у вас виденье "идеального" продукта и какие фичи вы хотите в него запихнуть в среднесрочной и долгосрочной перспективе. И от этого напрямую зависит выбор no-code инструмента для создания MVP. Об этом я, кстати, написал в статье, в разделе "Почему лучше делать MVP на ноукоде, а не коде? И как потом масштабировать продукт?", где были представлены возможные пути развития продукта.

Если мы, условно, берем конструктор нативных приложений Adalo - то там будет достаточно много именно что функциональных ограничений. То есть, например, нельзя будет сделать динамическую карту с перемещающейся геопозицией, аля как у Uber, сложные дизайнерские анимации. Adalo это действительно (за очень большим исключением) конструктор для создания прототипов, с которым лучше всего даже сразу идти к инвестору за финансированием.

У Bubble по сути функциональных ограничений нет. Они практически безграничные (с учетом подключения сторонних плагинов). Но даже и без плагинов встроенных функций очень много. Во вложении два скриншота: Первый скрин - список действий которые дает Adalo при нажатии на определенную кнопку.
Второй - список который дает Bubble.

Чисто по возможным действиям, в Bubble их раз в двадцать больше и это без плагинов. А с дополнительными плагинами это вообще безграничным становится, фактически.

Но тут есть нюанс, касающийся скорости работы. И это нюанс распространяется на все конструкторы.

Конструкторы очень чувствительны к сложной логике действий. Под этим имеется в виду: "сперва у нас открывается экран, мы на нем заполняем поля, потом нажимаем кнопку далее - переходим на другой экран, на этом экране есть 2 кнопки, если нажимаем на кнопку А - переходим в такой-то экран, если нажимаем на кнопку Б - переходим в третий экран". Очень утрировано, но суть такая - систему не стоит грузить сложной логикой последовательности действий, не нужно ее перепутывать, перемешивать. Система тогда может запутаться и начать сбоить.

И вот в этих ситуация мы, как no-code студия, будем говорить вам, как заказчику: "А давайте сократим количество "основных экранов" основного осуществляемого действия, и за счет этого облегчим нагрузку на систему, и позволим корректно работать альтернативным действиям (Кнопкам А и Б и открывающимся после их нажатия экранам).

Такой тип ограничений будет присутствовать при создании продукта на Bubble. Сугубо мое личное мнение - это не столь критичный шаг. Да, есть небольшой ущерб удобству и красоте. Но с другой стороны, продукт от этого не становится прям сильно неудобным и некрасивым, но при этом работает функциональная сторона.

Вот... как-то так)