As the article points out, the value of the Y combinator is largely theoretical/aesthetical, in both of which aspects your examples suffer greatly: they are ad hoc, lack abstraction/code reuse (which is why, perhaps, you needed more examples), and they look ugly (at least to my untrained eye). The point of the Y combinator is that it is a beautiful, mathematically precise, abstract, purely-functional way of expressing recursion.
"Ad hoc, lack abstraction/code reuse"? How does this
fix f = f f
almost_factorial f n =
if n == 0
then 1
else n * f f (n - 1)
factorial = fix almost_factorial
lack code reuse compared to
fix f = (\x. x x) (\x. f (\y. x x y))
almost_factorial f n =
if n == 0
then 1
else n * f (n - 1)
factorial = fix almost_factorial
? As for ugliness, well, it is indeed in the eye of the beholder: I personally think the fixpoint combinators that enable mutual recursion are pretty ugly, even more so than "(\x. x x) (\x. f (\y. x x y))".
The only real problem is that in my approach the recursive calls look like "f closed_over_functions... new_args..." instead of "f new_args..." but that's what the compilers are for: this transformation is called "closure conversion" and is pretty straightforward. Sure, if you have to encode those things manually, then perhaps using Y is clearer and may even be the only option if you can't mess with the original definitions.
