Aside from this, there's a higher performance and maintenance cost. Performance since you've turned a single function call into two. Maintenance because now you need to test this `atLeast` primitive when odds are YAGNI.
Tangent but this is one reason C++ works nicely with a more functional style with lambdas - the compilers are pretty good about optimizing away any overhead resulting from function composition etc.
The reason is simple: the compiler inlines the composition operator in the vast majority of (probably all?) cases, since the Haskell standard library source code marks it with an INLINE pragma:
-- | Function composition.
{-# INLINE (.) #-}
(.) :: (b -> c) -> (a -> b) -> a -> c
(.) f g = \x -> f (g x)
Haskell's competitive with everything but hand-tuned C code, consistently.
In a world where Python and Javascript are credible languages to orchestrate numeric computing, it seems ludicrous to imply that Haskell, which has superior code generation to these options in nearly every particular, is somehow "too slow."