One of the benefits of releasing a little and often is that a deployment is rarely big enough to cause major headaches.
The advantage of robust automated testing is that a rollback is extremely rare.
In terms of losing data from a new field I simply wouldn't worry about it. The organisation did well enough without it before, the amount gathered up to the decision to rollback won't alter the gravitational constant of the universe, particularly as the rollback implicitly stops recording that info.
In terms of how to rollback it is all in the planning and analysis. For a large table I will consider what data needs to be available on day one. Does all data need to be available or can I migrate from one state to another over a period of time?
Is my best strategy simply to create a new table and sp_rename to swap old/new versions?
I would focus more heavily on the things that cause rollback decisions to be taken and design them out of the equation as much as possible