TBVH I didn't think about naming it too much. I defaulted to Ollama because of the perceive simplicity and I wanted that same perceived simplicity to help adoption.
The motivation was edge and latency-critical use cases on a product I consulted on. Feature vectors arrived pre-formed and a Python runtime in the hot path wass a non-starter. You're right that for most pipelines the transformation step is the bottleneck, not inference, and Timber doesn't solve that (though the Pipeline Fusion pass compiles sklearn scalers away entirely if your preprocessing is that simple). Timber is explicitly a tool for deployments where you've already solved the data plumbing and the model call itself is what's left to optimize.
Fair point in general, but the risk profile here is actually quite low. The generated C is purely computational, with no heap allocation, no pointer arithmetic, no user-controlled memory, no IO. It's essentially a deeply nested if/else tree over a fixed-size float array. The "unsafe" surface in C is largely a non-issue when the code is statically shaped at compile time from a deterministic compiler pass.
Rust/Zig/Nim would add toolchain complexity with minimal safety gain for this specific output shape. Those were my considerations.