Personally, I prefer the look and feel of Twine compared to RenPy for your style of game. Though, the RenPy version does seem nice and I'd still play them if you switched over.
Going over your points first:
#1. Normal RenPy isn't too rough, so I don't think you'd have much issue learning and using it. RenPy tends to be more dialogue focused than writing like Twine.
#2. It will take time to get used to it, yes.
#3. That's possible in RenPy. You'll have to learn RenPy's styling methods. Compared to CSS, there is simply less knowledge available on the internet about using it, which does make it harder at times.
#4. Entirely possible in both engines.
#5. Possible, though I'd say probably more effort than you'd have in Twine. Though this depends on how much code you're willing/able to write.
#6. Scroll boxes are a bit rough for something like Renpy, and is why I prefer Twine over it for content with a lot of text. RenPy doesn't work great for normal writing longer than a few sentences. More often what you'd do is have dialogue boxes that turn that into dialogue or inner-dialogue (thoughts or narrator).
#7. I think that would be a bad decision. Though, when designing renders it should be designed around that most of the focus is on the upper-half of the image, but players should be used to hiding the lower dialogue box to see the full art. I'd prefer large images that are partly obscured to renders that are forced into a smaller box.
#8. I'm not sure I get what you mean here. Twine is perfectly capable of doing high resolution images. Are you saying that since RenPy has it taking up the full screen, you have to do higher resolution compared to Twine? If so, that certainly is an issue.
Of note:
- Twine Javascript + CSS + HTML (for Twine) is more 'general' than RenPy's scripting. RenPy has Python (which is general), but has its own formatting for display. Twine skills are more transferable to other projects on the web.
- Twine can run in the browser, but this probably isn't a notable boost for it for your project since it is many gigabytes and running a server that hosts that could be a bit rough.
- Twine has the benefit of multiple formats. So, if SugarCube ever goes out of style or gets an update (which there is actually one in planning), you can simply swap to another story format. They aren't all the same, but the Javascript+CSS+HTML transfers. With RenPy you get more locked into their way of doing things.
- I don't believe there's any visual editor/graph like the Twine application for RenPy. Though, one to represent the graph could be made for RenPy with some effort, I don't believe it exists. (Like, for Twine, there's the Twinery application with its graph, and the VSCode extension that has its own graph for Twine/Twee files).
- RenPy is harder to get working on mobile. I don't think this is significant, though.
There's certainly some points of comparison that I've missed, but that covers a portion of it.
Overall, I prefer Twine because it is better for works with more writing, of which yours tend to be.
