Witcher123's reply is pretty similar to what I would've said. Also wanna preface this saying I'm not a coder but have done some background research into coding languages behind both. If I am incorrect on anything please call me out.
Like yes there isn't anything wrong with Unity, it's just that I don't really understand why it's being used for this game when you can use a much simpler software to develop this game, especially since the dev is still having troubles developing on it. RENPY runs on Python, which from my understanding is meant to be easier to develop with. As I believe that coding issues is what was stated to be the main reasons for the bottleneck in the development cycle for this game, the dev might find it easier to develop on RENPY. The income system (heists/bordello/strip club), the sex scenes/gallery, the map and open world function can from what I've seen be done in RENPY based on games listed on this site, and there most likely exists templates and tutorials to do each one considering how many RENPY games have these functions or something similar. Heck, some of the best animated sex scenes I've seen from games on this site have been from RENPY games, so I don't think adding a paralax scrolling system would be impossible.
The biggest consideration as to why a move to RENPY would improve the game currently is because of the save functions and gallery. With RENPY you can pretty much have as many save slots as you want, a large improvement from the existing 3 slots and (I believe) more easily set up a replay system with the gallery function, which currently just gives you either a still image(aside from the scrolling) or scenes that are repeatable as is. Again, all of these seem to come with the function built into the system (ie you can type gallery in and I believe you just need to choose which scenes to load) and there are tutorials to do these on youtube.
Yes, Ren'Py can probably be used for a game like this (with some limitations maybe), I am not sure if it supports enhanced image handling like animated moving overlays, but let's just assume that's possible. But trust me: If he's having trouble coding with Unity, he will also have problems coding in Ren'Py, maybe even more, since it has less protection agains coding errors (as we have seen in plenty of games). I have taken a look at some Ren'Py games about how variables are handled and it's a horror for everyone who is used to write complex programs.
Both gallery and saving can be done just the same way in any other language, the limitation here is a decision, not a limitation by Unity. But yes, I would prefer the standard handling over what he did here. Savegames in the registry ... I had a hard time to believe that. The good thing about it is probably that this way you can save every single step without worrying aout stressing your hard drive. Windows handles the registry cache.
Im not saying that Unity or Ren'Py are better suited. I'm saying it's lot of work to switch.
If you want to know the "why" he decided for Unity, you best write the dev a message (just ask nicely what his reasons were to choose one over the other, without you think it was a bad decision. No one likes to hear that). I could only tell you why "I" would prefer a high level language over a script engine. Usually the answer to such a question is "At that time it seemed like a good decision" or "I know that language, but not the other one.". In my case an additional reason would be that the software needs to be reliable. I don't know if ren'py supports something like Unit- or e2e-Tests, where you create and run automated tests of all your functions before a release. For my line of work those are essential.
For something as simple as a visual novel I would probably go for such a system however.
Ren'Py has been around for quite a while, but only recently it became very popular for simple novel style games. Before that, Unity was the way to go, even for simple games like the ones we see here. Unity is a whole other level, you have so many more options there, it's hard to decide where to start. It all depends on the goal you set for yourself in which directions your software should go.
About the "why not switch", there is two counter questions: Is it worth the huge amount of work and trouble? And question two: Would the patroens be willing to pay for that time without getting anything new?