In addition, keep in mind that the reason so many RenPy games exist is that it is relatively easy to create a project. But that ease means that the majority of projects are written by people who barely understood what they were doing. Just because you see the same code used over and over doesn't mean it is the better solution, just the one that everyone else copy/pasted the most.
Regarding this, it's due to the fact that Ren'py is a relatively flexible engine.
There's rarely just a single way to do something, therefore everyone will tend to come with a solution that follow his own mind process.
On top of this, there's the fact that Ren'py have an average of 6 updates by year, with more than 15 years of existence ; all this with, until the 7.x version, a strong care regarding backward compatibility. What mean that, over the years, the native capabilities of Ren'py itself evolved. What previously needed a hack can now be done natively, or at least more easily.
And finally, like Ren'py offer a direct access to Python, you can extend by yourself what is feasible.
All this lead to a game code either looking like so many others, or at the opposite looking like no others ; depending if the other copy/pasted a lot or, at the opposite, tried to come with his own solutions. There not really an in between.
In the end, all this mean that the best way to learn is to hear/read what others have to say, but also to experiment by yourself.