The CRUD concept itself is very old (I know of implementations from over 20 years back). It is also kind of crude/limiting in that operations apply per record (from what I have seen myself). This is counter to more efficient set based thinking, which you need to do when working with large volumes of data.

In a way, completely depending on CRUD is a step wackwards to the day when there were products that had triggers that fired per record instead of per set of records. As a developer I can see the ease of use however, but it should never be implemented in a way that reduces the options for a DBA to optimize things after deployment.

If you need one record, manipulate one and store one, CRUD is fine. Beyond that, it becomes itself a roadblock for performance and efficiency.