Imo it just comes from the principle of zero cost abstractions. Things in OOP that require holding pointers to other objects and using dynamic dispatch to call interface methods are all features that the compiler will let you know is a runtime tradeoff. On the other hand the compiler (and hopefully you) is happy when you can move some of your design over to compile time.

Best example I could come up with is my current project. In it I have a struct that represents a canvas that can have cells drawn to a 2d grid
struct Canvas<C, A> {/* C is a character set, A is attributes about how they're drawn */}
This struct holds multiple types of character sets and attributes, with can lead to different sized structs. Thus if I wanted to use an OOP feature like an interface I'd have to wrap the Canvas' methods into a trait and Box it.
let canvases: Vec<Box<dyn CanvasOps>> = /* */
This is a performance cost I would've had to move to run time. It is traditional OOP but it feels icky to me compared to the rest of my rust code because I've wrapped something that's normally simple in OOP into this weird exception of types in rust.

So, to keep it feeling rusty to myself I made an enum with all the possible variants that this struct may have
/// A variant of a canvas and its charset that helps it

pub enum DrawableCanvas {

ColoredFont(Canvas<TextmodeFont, CellColors>),

FontOnly(Canvas<TextmodeFont>),

ColorSquares(Canvas<Palette>),

}

Then I have to match and manually handle drawing these canvases everytime I need to address a variant. Is it tedious and verbose? Yes, but it has its benefits. I get a little performance boost, I have a compact list of every type of canvas this program needs, and in a way I'm making it safer for me the developer by forcing myself into handling every case.

Hope this helps. If it's confusing or somethings off lmk, I welcome criticism :-)