For many, the well-defined collection of data is realized in a relational database. In this case, the challenge is mapping this data onto exact requirements for specific data entry screens or reports.

With complex business rules that cannot be easily implemented via database constraints or triggers, or where the same rule is located on more than one data entry screen, then there is a justified need for an intermediate "model" layer for business logic. However, many applications out there just don't have this complexity. In these cases, having an intermediate model accessible via JSON API may be over engineering. You have to double your mappings. A new feature requires that more code be touched, in different parts of the application. For applications with simple business logic and screens that closely map the database structure, this additional layer may not be worth it.