I hated maintaining a mid-sized Delphi code base too. Although this one might have to do with the fact that the main product code base was basically "a separate repository per each customer, copy-pasted from the least messy one when the development started".
I also remember it was very easy to slap a simple CRUD GUI on top of an existing DB. The trouble started when you had to evolve this. Putting some non-trivial reusable business logic between the UI and the DB was non-trivial.
> Putting some non-trivial reusable business logic between the UI and the DB was non-trivial.
It took me a good long while to figure it out too, but once you got the hang of it, it wasn't really all that complex. AFAICR, the trick was mainly to put object definitions (that pretty closely reflected your DB table structures) and functions/procedures to manipulate them in your data modules with the DB components.
The main problem, IMO, was that these strategies weren't really documented anywhere, you had to figure them out for yourself. This, in turn, was AIUI probably because Borland itself wanted to upsell you to the Enterprise (and later Architect) version, while independent companies also wanted to sell you their various (more-or-less-)fancy "middleware" alternatives.
I also remember it was very easy to slap a simple CRUD GUI on top of an existing DB. The trouble started when you had to evolve this. Putting some non-trivial reusable business logic between the UI and the DB was non-trivial.