If you want to eventually have a game with good gameplay, you need some non-hair-pulling process to move from "game doesn't crash" to "game has sane, understandable, non-bugged mechanics that I can understand and enjoy seeing work".
If you start off with complicated logic that is hard to reason about or abstract, you'll never have a way to move from the former to the latter. Btw, people have written long, abstract, best-selling books about this (good software design), it is one of the most talked about things because getting it right is A) hard B) pays off in spades.
One of the most important things that is common to, for example schools and brothels, is that they are both objects that add, hold, and remove girls, and they modify the girls they are holding. And well, stuff happening to girls is probably the core element of the game...
So indeed that speaks extremely strongly to the usefulness of a common interface for these things.
I also remember seeing conversations about girls "having lives" outside of the player control, e.g while they are in the world, etc. Having a common interface for these locations also would make this sort of feature far easier to implement.
Without it, you could fix one bug, or introduce one feature in x location, and then a week later wonder why y, z and w locations don't work as you expect. And then fix a bug for that feature in z, and then two weeks later wonder why there's a similar bug that's just come up in x again. You might remember that you fixed it two weeks ago in x, and then copy and paste the 'fixed' code back, but in the process forget that you changed x's behaviour subtly the week previous, and thereby introduce another bug with the c+p. The ability for this to happen when you have more than one developer also grows exponentially, especially when there's no formal testing process.