To write an OS you simply need to be able to compile code that can be launched by a bootloader. That's it. You don't need explicit control over the layout of your data structures in memory.
I'd hazard that the engineers at Apple are perfectly qualified to identify what is and isn't a "systems language" working for one of the few companies that has actually developed several from scratch (I am referring to A/UX, Mac OS Classic, Newton OS, and NeXTStep / OpenStep / OSX / iOS in case you're wondering).
I assumed you were talking about there being a well-defined relationship between a struct definition and its layout in memory. As far as I know, Swift can allocate chunks of memory and play with bytes explicitly without resorting to assembler, so I think that's pretty much covered.
That said -- if Swift were to be used for systems programming, you'd probably want better support for all of this stuff (starting with inline assembler), and for all we know Apple is already tinkering with this stuff in-house, it just hasn't released it yet (e.g. because it's in flux).
Since it's perfectly possible to do inline assembler via a straightforward kludge, adding that particular feature to Swift would be almost trivial.
As things stand, it would be pretty easy for a third-party (once Swift is open sourced) to add the necessary niceties to the standard libraries or Swift itself, so these kind of objections are pretty minor. The big question is low-level performance, and Swift has real advantages over Python and Go here.
I'd hazard that the engineers at Apple are perfectly qualified to identify what is and isn't a "systems language" working for one of the few companies that has actually developed several from scratch (I am referring to A/UX, Mac OS Classic, Newton OS, and NeXTStep / OpenStep / OSX / iOS in case you're wondering).