Short answer: If you want users to have the choice on whether to accept the changes you make or continue using their own configurations, then this is the approach you'd need: "... ask them to reconfigure their view every time something changes?"
Here's the thing - users who haven't yet personalized their views are already using the system (administrator configured via Studio) version of the view. If you change the configuration of that view in Studio under the Admin Tool, all those users will automatically get those new changes without any publish taking place.
Only the users who have configured their own versions of the view (and so now are using a 'user' version of the view) will not see them - UNLESS you publish or they themselves Restore to Defaults, which essentially is an action to remove their custom view so that they fall back to the system view you (recently) configured and everyone else is using.
So it sounds to me like you just need(ed) to make the changes, and then advise users to either pick up the new fields in their own custom views if they want them, or they can selectively choose to Restore to Defaults by themselves in order to do an isolated form of publish. Then any users who just prefer to keep their own custom changes will be left alone.
This only works to a point; if you make fundamental changes to existing fields (deactivating or otherwise changing their definitions such as making them hidden/required in filters), that might necessitate a Publish since the old format of the attribute would not be compatible with the user's current filter and list views, and so the custom ones need to be dropped. Adding and configuring new attributes though wouldn't enforce that action.