I was made aware of this thread's existence during WWDC, and I am also interested in seeing Swift progress forwards as a more realtime-friendly (or "truly systems level") language in the future.
Unfortunately, for an AudioUnit that's written in Swift right now, any progress made via the above work will be hampered by the fact that we're going to get additional swift_allocObject calls inserted into the code that's executed in the audio unit's internalRenderBlock. More details here: [SR-9662] Subclassing an Objective-C class that returns a block unexpectedly (?) emits an unnecessary reabstraction thunk · Issue #52106 · apple/swift · GitHub
In addition to your checks that guard against allocations, we'll also want to have checks to ensure that there are no surprise locks that are taken behind the scenes in the runtime when we interact with certain reference types. Especially in the cases where someone might (as an example) accidentally try using an AVAudioPCMBuffer instance, which is backed by an Objective C implementation, and hence unsafe.
Perhaps what we need is a "runtimeless" subset (superset?) of Swift that would allow us to build out libraries/packages that don't have access to the standard library (or an alternate version/subset of it) before we could achieve something like this.
But that'd mean there's no heap-allocated types, no ARC, and I'm not sure that such a thing would even closely resemble the Swift that we know today. 
Anyway, count me as a 
for cheering on any efforts in this direction. I've got a ton of Swift-powered DSP that I use in a non-realtime context, and would love to get some more mileage out of it, and stop maintaining parallel C++ and/or Rust implementations…