I really appreciate everyone's perspectives. I don't think there's a wrong answer here. We each have our own personal preferences for code style and philosophy. If I were contributing this code to a project managed by Hyeonu or H2CO3 then I would happily use one of the safe alternatives and carefully document what the associated "trick" (using Box or Option) is doing and why it's likely to be optimized/zero-cost.
Let's also keep in mind that the standard library uses unsafe under the hood for Any::downcast_ref et al. So technically, all of the solutions here are unsafe. It's just a question of who is writing the unsafe code, how much unsafe code there is, and how well it's audited.
I think of unsafe as like fire or a sharp knife. You depend on it at some level, but you had better respect it.
My personal view of this is that every use of the unsafe keyword carries a relatively high maintenance and auditing cost. For the standard library, that cost is borne by the Rust developers rather than me, so I don't have to worry about it. If I'm personally writing unsafe code, however, those costs fall squarely on my shoulders; skimping on them leads directly to technical debt that will come due at an unknown time in the future.
In this situation, I'd start by encapsulating the Option trick into a function with a reasonable signature that I can use everywhere. Once I'm confident that my program is correct, I'd consider rewriting that function to use unsafe directly if profiling reveals an actual performance bottleneck in the safe version.
NB: This isn't hypothetical in my case. I knew how to do Any-based specialization in safe code because my thesis work needed this same capability. In my project, the safe specialization code was fast enough to not be a problem.