Weekends are pretty much mandatory as a DBA, whether a GIS DBA or not. That being said, I don't see a need for this to occur every weekend unless there is some very special, specific need to do so. We have what's called "Database Weekend" at my organization where we have block time (planned downtime) for our production databases in order to perform necessary maintenance that couldn't otherwise be done when users are connected. Friday nights at close of business tend to be the least disruptive time to begin this type of work. For us, this includes rebuilding geometric networks, compressing to state 0, making schema changes that require exclusive locks, server patching and rebooting, and a variety of other tasks. The number of people needed for this type of work is dependent on the complexity and size of your environment as well as the amount of maintenance that you need to do. Database weekend is once per month for us, and we publish the schedule in advance so users know that at 5 PM on Friday night we will be taking the databases down. We send out an email to the user community a few days beforehand in order to remind them of this, and we send another email to them when the databases are available again for the users (this could be late Friday night, Saturday afternoon, or Sunday morning depending on the volume of work). So, I think the answer to your question is "yes, you should plan to work weekends but probably not every weekend". If you have some control over when maintenance is done and how it is structured, then I would suggest setting up a workflow with block time (e.g., planned downtime) like I've described above. That way everyone knows what to expect. Changes that require down time should wait until Database Weekend, unless there is an emergency of some sort.
Also, analyzing objects and rebuilding indexes can be done with users connected during regular business hours, although many will script this to run nightly or weekly. I would also recommend a nightly automated reconcile and post (depending on your workflows and versioning structure) followed by a compress if your edit volume is what you say it is. That should reduce the wait time for your block time compress when and if you need to go to state 0. One additional thing for the moment... if you want to prevent users from accessing the database(s) while you are performing your QA/QC prior to reconciling and posting, there are many approaches that work for this, one of which includes temporarily locking non-essential database accounts. I've had good luck with this approach because I can lock out regular users but not folks on the database team (i.e., administrators). Of course, you'll want to script this if you have a lot of users.