I agree with your view point and concerns.

That is why we took the approach to reduce the number of components and integrate everything in Kubernetes, especially with logging (we directly log in JSON to standard output) and the usage of application containers, which enables us to cover the case of troubleshooting via the fencing mechanism (your pods are up, you can access storage, but Postgres is down, giving you the possibility to check even possible data corruption issues).

Also, the status is directly available in Kubernetes, so in our view easier for Kubernetes administrators.

Finally, the source code is open source and directly available for inspection - if you want to understand what is happening.

So, instead of (re-)inventing the wheel, with something like CloudNativePG, I would encourage your team to look into this, perhaps help contribute to better documentation. I believe that would be the way to a) get your project to benefit from using an operator for Postgres (hence scaling / benefitting more and more quickly) and it would b) help a great bunch of other folks to also benefit from that shared knowledge.