There didn't use to be any rules to play by. Official "front door" APIs are a modern phenomenon. They started being offered, and rugpulls were rare, so we got complacent and started using them rather than reverse engineering first-party APIs.
Even factoring in the risk of a rug pull, it makes more sense to use an API than spend ongoing constant effort reversing a first-party one that will keep breaking on your users randomly and need urgent fixes all the time.
I mean, if you have a public API, it makes sense, engineering-wise, to build your internal API on top of that, doesn't it? But apparently not everyone does it like this.
So, for example, if those clients have only a fraction of the features of your internal clients, it may make sense to relegate them to a separate, stable backend service while you work on your internal one. But if there's just a couple of internal methods and everything else has to be public, it probably makes sense to have a single backend.
There's a lot of in-between cases, and that's where an engineering architect shows his skills in choosing the right approach.
Old reddit for example uses the reddit API essentially directly. now with new reddit, there's been a split, and it looks like from my count that reddit is currently supporting like 7 different APIs internally, parts of them all used in various different places. The reddit API is pretty functional and most of what anyone would ever really want to do was already supported in the API (and therefore available basically with few current restrictions).
Few of the actual undocumented/internal APIs on reddit are all that interesting.
[1]: https://www.reddit.com/r/redditdev/comments/14nbw6g/updated_...