I agree, you are definitely making a trade off.

That trade off is essentially developer time for performance.  However, serving application based (internal) webpages is usually something where you can know about how many users to expect.  In my case, while we have a good number of users, we don't typically have many concurrent users - I'd say it would rarely go over 40.

SQL Performance and web performance have not been an issue - so far  - with basic editing or listing of data.

I have enountered performance problems with a crosstab/pivot table report design based on metadata, but a rewrite of the design solved that problem.

I'd never recommend this approach for someone expecting several hundred or more concurrent users, but in smaller databases (tables < 1,000,000 rows) it is lightening quick.

As a single developer I could never have coded pages for all the applications we are currently supporting - this approach allows me to implement and support more applications per $ spent.