I tend to agree along these lines--and my vote is for either stick with SMF or migrate all current content to Discourse--as decided by whomever takes over management and their skills/preferences for managing and maintaining the website operations.
I am not a fan of less established or experimental software (i.e. anything blockchain based) for something as important as the forum. I am also not a fan of anything that has any more friction than necessary for lurking/participating (https://bitsharestalk.org/index.php/topic,23705.msg302021.html#msg302021).
To be clear, I am assuming whoever takes over will have full control over the domain name, the forum server software + database, and any additional software like an SMTP server for sending emails.
If sticking with SMF, it's important that it be kept up to date for security purposes (we are currently several versions behind). This is also the least surprising path since there is unlikely to be any outcry for keeping things as-is.
If moving to Discourse, I think it is important that all threads and user accounts be migrated. If everyone had to re-register, then that could kill the forum. Performing such a migration manually seems non-trivial though: here it says https://meta.discourse.org/t/migrating-to-discourse-from-another-forum-software/16616 it requires manual review and editing of the migration script, which is a complex script (https://github.com/discourse/discourse/blob/master/script/import_scripts/smf2.rb). The best bet for a migration (and possibly ongoing operations/maintenance) may be a managed hosting solution (https://meta.discourse.org/t/what-are-some-reputable-managed-discourse-hosting-providers-out-there/54702) like https://www.discoursehosting.com/pricing/ or https://payments.discourse.org/buy/ which also will do the migration for you (eg https://meta.discourse.org/t/discoursehosting-migration-service-for-your-existing-forum/12201). Self-hosting could be done on something like Digital Ocean (https://www.digitalocean.com/community/tutorials/how-to-use-the-discourse-one-click-application-on-digitalocean) but it would still require a complex manual migration and at least an SMTP server for sending emails.
Perhaps you didn't see it, but if you have what is your objection to keeping the current SMF forum, locking it down into a read only state, and moving ONLY the user accounts over to Discourse? This was DataSecurityNode's suggestion and I believe it has great merit. I agree that re-registration should
not be required. Migrating user accounts will be far easier (tho issues could arise) than then entire forum content.
I think a managed host path should be investigated as well. Even if the costs were not prohibitive I still think we should ONLY migrate user accounts and lock down this SMF forum in a read only state. Although the user base is much larger, I manage an SMF forum myself, and it is not a heavy resource intensive application. It would be worth checking into whether the Discourse hosting might also include hosting for this SMF forum as well. If not I still believe it should be preserved as is in a read only state.
A read only state also reduces the maintenance requirements. As long as a full backup is preserved, and that could be done by several trusted users, should the forum be corrupted or compromised it could be restored from a backup fairly quickly, and speed wouldn't really be an issue in doing so anyway, given it is only a reference library.
Migrating the SMF threads will be wrought with problems and take a significant effort. There are likely to be complications and incompatibilities. All of that can be avoided by just providing access to this SMF from Discourse as a reference.
As to who should be responsible or how to manage the servers and domain, I don't think we should be thinking that a centralized, single point of failure approach is best. I also don't think a group or committee makes sense either. We just need to have more than one person with admin access in case the primary admin can't act for any number of reasons. There is a very small risk that one of the admins could change passwords and lockout the others, but I believe the chances of that occurring are extremely slim if the people are chosen well.
Perhaps we should consider control of the domain separately. That will require far less interaction, almost none after initial setup, and thereafter only to renew the it periodically. That could possibly even be automated to be paid directly via the blockchain.