Hmmm, I've only poked around in the code for a few games.
If you want to see a number of variable interactions in action, Lab Rats isn't a bad place to start. Vren at least tries to keep things somewhat organized (pics, etc. declared at the beginning, using labels to break up time perods at each locations, etc.), although some of his screens are handled in script.rpy instead of screens.rpy. At least that was the case in 0.3... There are some fairly intricate variable interactions going on in Lab Rats.
DMD is a fairly straightforward example code-wise, although it breaks things up a lot, with script sections handled by day in separate files. Depending on the structure of your story, this may or may not be useful to you.
The best thing you can do is 'not buck the system'. 'The Choice' (included with the RenPy SDK) gives you a basic starting point, and it's not a bad one. While I think that RenPy over-compartmentalizes things at times (thinking of some of the variable/style declarations here), it's good to take the time to understand how the RenPy developers have broken things up, so that you can make a more informed decision as to what will work best for you.
If you are developing games 'on the fly', it's hard to know all of the variables and such you'll eventually want to use right out of the gate. For your sanity, however, it's best to do some initial/default declarations at the beginning of the script (or in a separate 'variables' file as done in D.M.D.), so that you can find the list of variables you are using easily. You can break these up easily enough by day, etc. with a simple comment. Using the comment out (#) tag is a great way to make notes about something you are doing
Example:
# day 4 variables
$ went_to_grocery_store = False
# day 5 variables
$ went_hiking = False
$ acorns = 0
$ amy_intrigue_level = 0 #this tracks how interested Amy is in making the MC's life more difficult
Breaking up sections with labels can make things easier to find, but I'd suggest not going overboard with this. I was just looking at some code recently where the interaction at a location was broken up into 7 different label sections. some of these were simply 'dialogue breaks', and the story always led to the next label. So while this increased the 'letter count' a bit, it wasn't really accomplishing anything. Some of the other labels WERE important, as they were 'jumped to' by choices made during that part of the story.
Using jump excessively may just be making things more complicated when they don't need to be. If you are always 'jumping' to the same point (i.e. no dialogue fork), and are only jumping there once, a
#### Next part of story - going to next store aisle (this is an example, put whatever you need here to give you the mental cue you need to remind yourself what's going on)
to break up the dialogue can be just as useful as a jump, without adding that 'extra step' for RenPy to track.
Breaking up your ingame images into additional subfolders (see DMD) can be useful, but if you have a group of images that you keep re-using in subsequent updates, having those in a bunch of separate folders might be just making your job harder. Sure, there's the initial 'pic declaration list' during init (assuming you declare your pics at the beginning of script.rpy), but it makes sense to put all of your location-related background in the same folder, as opposed to scattering them across a bunch of unrelated folders. You can break these up by location into separate folders, but breaking them up by day may be less useful if you end up re-using them on subsequent days.
Remember, you are organizing things for YOUR sanity, so whatever works best for you in your development cycles is what you are looking for.
---
In short, before you start writing, it's worthwhile to think about YOUR workload, and what will make it easiest for you to write/develop your story. Not all situations will be the same.
It's also very helpful to do a rough 'diagram' of your story in advance using tools like flowcharts, dialogue trees and such, so that you can picture how things are going to shake out in your story in advance. Sure, you'll end up changing a bunch of these forks as you begin writing the details into the story, but this will give you a roadmap at least. This will also hlep highlight some 'signposts' as to how to better organize things.
