Earlier quoted context omitted.
It's a limiting, but saner approach for any larger app/company. It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals. Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.
> Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future. Surely you'd just want to be calling the internal API that the other endpoint is using behind the HTTP endpoint? If you're in the same process (big if, but nothing to suggest they aren't), there's not a lot of sense serialising out to a socket and back again rather than making a function call.
I am not saying everybody needs to do microservices but my experience with monolith is bad. You want at least "some" services and the html-serving service shouldn't usually own the data. User data belongs to user service, report/analytics data to analytics service etc.
Just from the security point of view, the stuff facing internet should have minimum rights to read/write anything. Definitely not direct function-calling or db access.