Well, FWIW, these are the main benefits to using NSCoding over Codable. See a tangentially-related post here, but these requirements would be the main reason I would recommend someone sticking with NSCoding over switching to Codable.
As you note, Codable doesn't support polymorphism in the same way that NSCoding does (and this is a feature), but at least it can be worked around depending on your specific requirements. Circular object graphs are only partially supported (well, this depends on the Encoder/Decoder and none that I'm aware of readily support it), and are a much bigger pain to work around.
Based on this alone, it sounds to me like your requirements make NSCoding the right tool for the job. As @jrose notes in that quoted comment, NSCoding isn't going away, and is fully-supported tooling; if it's the tool that best solves your problem, use it!
At least on this point, you can keep your types as migrated to Swift, but adopt NSCoding on them instead.
it might make sense for me to use async/await in conjunction with
Codable,
As an aside: Codable as written doesn't support async/await in any meaningful way, and I'm not sure that it could. If we wanted async initialization and encoding, I think the Codable system would likely need to be rewritten from the ground up.