That's as simplified as that particular game's code is going to be able to manage. Automated tools like URM are going to need to have a specific criteria for what they include or don't include, and since every game dev may do their game's important variables completely differently, URM's trying to do its best to show you what appears to it to be relevant. If you have ideas for specific filters/criteria for what shouldn't be considered relevant, call those out.
You mentioned wanting to see simpler readouts like "characterlove +1" in the code view, but the choice in the game above didn't change that kind of variable. It used that kind of variable as a branching condition instead, which determines the result stored in the string var
[girl]_relationship
instead (and on one branch, unlocks a gallery scene in persistent, unlocks an achievement, and increments the game's harem size counter). So should it not include string variables? Should it not include the harem size counter variable? How does URM know that the haremcount variable isn't a girl relationship variable? On top of that, variable names are almost infinitely variable, completely up to the dev, and can be almost anything. If the dev wanted to (though I pray they don't), these variables could have been quite literally all gibberish, and it would work the same as long as they were used consistently.
Lastly, other people might have different opinions about what variables are relevant; for instance, someone who doesn't care about 100% completion seeing the above code summary wouldn't care about seeing the
persistent.g_iris_02a
gallery unlock variable or the
unlock_achievement
call or not, but people who do care about 100% completion very much want to see those to know which choice leads to the sex scene/unlock and which doesn't.
(Oh, and just as an example of how weird a dev can get with variable names if they really want to, this is a real character definition class from a real game:
View attachment 4779183