What does boxed_local do? Just curious why it reduces monomorphizations

boxed_local is just a part of the story.
The problem boils down to the fact that we have a function such as follows (it uses FnOnce and not Future, but the concept is really the same):

fn function<R>(a: impl FnOnce() -> R) -> R {
  (a)()
}

impl arguments get desugared by a compiler to:

fn function<R, Fun: FnOnce() -> R>(a: Fun) -> R {
  (a)()
}

Then, the problem (and excessive monomorphizations) come from a fact that each closure you pass into that function is a separate instantiation of function. It also means that a call to a can be inlined within the body of a monomorphized function.
boxed_local turns our impl Future<Output = R> into Box<dyn Future<Output = R>. This is one type per Return type, and not a separate type per closure. It still depends on the return type, but by boxing and erasing a type we're going from O(number of calls to spawn) instantiations to O(number of return types) instantiations - which is likely to be way smaller.
This has downsides.
For one, you need to allocate in order to perform that kind of type erasure. It's not always necessary (if you can use a reference), but in our case we can't, so..
The other downside is that the compiler can no longer inline the call to your closure, because of type erasure.

On the flipside, it does not necessarily have to degrade the performance of your program:

1. In our case we're making shitton of monomorphizations which (I'm just speculating here) might contribute to trashing of instruction cache. On main each instantiation of spawn is a separate code path.
2. Inlining really matters when it can unlock additional optimization opportunities for the compiler. Again, I don't think we are operating at a level of granularity with performance where whether something gets inlined or not makes a huge difference to us (esp. with a tradeoff being longer build times).

Thanks for such a detailed explanation! I was about to ask about memory allocation but you covered that already.