And as an aside, CLAP has almost nothing in it that LV2 didn't already offer, and nothing that could not have been added to LV2 using the extension mechanism, but a rather severe case of NIH pushed things in the direction that they eventually went. It's quite unfortunate.
Rack performs single-sample processing. DAWs (all of them) use block-structured processing.
For a DAW to host modules that are designed for single-sample processing would always require an intermediary. It might as well be Rack.
Because the modules are written to do single sample processing, which creates some design imperatives that are quite different from those used by regular audio plugin APIs where blocks of samples are passed around.
"But, " you may say, " isn't single sample processing just passing around blocks of samples with a size == 1?"
Well, sure, technically that's true, but you don't write code the same way if you know that the size is always 1.
Ergo, you're going to need something to execute the modules in a single-sample style, not block structured. That intermediate will be functionally identical to Rack.
Rack's API is completely open source, and anybody else could reimplement it. It would be horrible as a general audio plugin API, but it's pretty good for "rack modules".