But once the project is large and popular enough (and PostgREST arguably is), you don't maintain it yourself anymore. Keep in mind than in any case you're probably using PostgreSQL and Linux: major pieces of complex C code that you probably can't and won't maintain yourself.
To be clear, I do think being able to understand the source code for the system that you're running on and even submit patches or pull request is nice, but this is not what you pointed out as your reason, and it's also never going to be my #1 priority for a production system. For instance, PostgREST looks more mature than pREST and that's a pretty big consideration for a production system.
edit: Point being every day you use a lot (i would say majority) of software which most probably it would be very hard for anyone to "change" and yet this seems to work. There's no point in making a decision to use some software by thinking "am i personally able to understand it's codebase". By this logic there is very little software one person should use, no one is able to know everything.
Let the experts (in that particular software) work on it, while you contribute to the things where you are an expert, everybody wins.
I remember an article here not long ago about the distinction between an expert and a smart person, interesting read.
I also prefer Python and Go but to say I would not use the software because of the language it's written in just sounds silly to me. Heck, I really dislike PHP but would still use PHP-software when it suits my need.
Which is exactly why I don't use software written in java, haskell, nodejs and prefer things written in python or go.
Given the choice between PostgREST or pREST I would chose pREST every time simply because if it breaks or ends up unmaintained I would have a chance in fixing it myself.
I'm sure there are many people who have the exact opposite stance, and that's fine too. This shouldn't be surprising to anyone.