Hmmmm ... I'm not sure what the implication is here, but I imagine it's that RAP would tie you down to a fixed structure that can't adapt. Like every other design it has its limitations, but actually by virtue of its extraordinary consistency a RAP-based design should be dramatically easier to modify than most hand-written apps. The consistency alone would lead the maintainer to be able to deduce the scope of the changes.

In a typical design, for example, a schema change to one table would require you to alter the table, then alter all the code in the database associated with that table, then alter the data layer to account for the change, and then finally adapt the business rules and UI to take advantage of the change. With RAP, you alter the table. Then RAP regenerates the database code and the data layer code for you, and the code is flawless. Finally of course you then have to modify the business rules and UI (as before) to take advantage of the change. The RAP cycle takes a lot less time and the code-generated portion is error free.

In my experience, which now spans over three decades, the apps that are the hardest to change are the hand-written ones with lots of inconsistencies. Once again I'll use the car analogy. Which is easier and cheaper to maintain and adapt .... a custom hand-built car, or one that came off an assembly line? I'll take the Honda Civic, thank you.