The alternative way is to use the factory nms:subscription feature (with @address or @adresspecific fields) and extends nms:subscription depending on your specific needs.
But it means that your delivery mapping becomes nms:subscription instead of nms:recipient, so take care for your count workflows and deliveries personalisation, change dimension accordingly. It is bit more difficult than Vipul's recommendation, but more out-of-the-box oriented.
Since you will still be using the default nms:recipient table though with some custom extensions you will not be impacted. The link you have shared deals with scenario where your organization doesn't wish to use recipient table but have their own dedicated table say customers to hold target audience data.
Unsubscribe links contains the ID value of a recipient in encrypted form. it is this value used to locate a recipient on your landing pages.
Email doesn't play a role here.
So on the unsub page you can define the logic to mark the parent @blacklist field as 1 or if you want to opt them out of a specific channel mark @blacklistEmail field as 1.
If unsubscribes are being done from a specific service then still you will have the PK value of recipient in unsub link and the same will help you unsubscribe a recipient from a service of choice irrespective of their email.