Integrating object code into Objective C or Swift is easy, commonplace, people do it all the time.
Rust can generate object code all day, you can insist on the C ABI anywhere you need to, and then you can bring in anything from cargo you want. CocoaPods is... not cargo.
If the target is to be platform specific, then reducing the amount of compiler toolchains, IDE/editor plugins, and language knowledge required across team members is a good thing.
If the purpose is to go cross platform, then it is another matter.
Then again this is a matter of opinion, feel free to disagree, I am not here to change your mind.
They mentioned elsewhere it started off as a fork of the Xi editor which is written in Rust. Xi separates the text-editor idea into backend and frontend, and Xi itself is primarily the Rust-based backend which concerns itself with making editing operations very fast, and then you can write a front-end client for whatever language/platform you want.
In this case, they can use a fast Rust backend for multiple platforms (or just one) and then use Swift to make a nice, native front-end for MacOS and other native UI languages for other platforms if they wish.
Which is why I made the point on my comment about what the cross platform goals were, but the RIR folks are too quick to jump the gun in any kind of critic and only read half of it.
Cross platform future aside, they want to use all the good libs Rust has for ropes and the like. The code is based on another editor earlier work, and that's in Rust.
They also know Rust so if they want to use Rust, what's the problem in using it? They don't seem to have any problem with building a UI on top, it's built and looks/works fine.
Integrating object code into Objective C or Swift is easy, commonplace, people do it all the time.
Rust can generate object code all day, you can insist on the C ABI anywhere you need to, and then you can bring in anything from cargo you want. CocoaPods is... not cargo.