Because the compiler doesn't know to look for this way to wait for the end of the thread. The language is Turing complete, but the compiler can only look for a finite set of subprograms that wait for the thread, so it can never catch them all.
The compiler could have a special case for looking at joins. But that's extra complexity that gets you almost nothing in return. Instead, Rust developers decided that it's better to do it in a library and created the scoped thread the article talks about.
Thanks for explaining, though since the code is formally correct - taking into account thread joins can't really be considered a special case. I suspect thread spawning and joining would need be a language feature instead of a library feature to enable this.
It doesn't need to be a language feature. Scoped threads are a library implementation of the idea of joining right away. The issue is that spawn is specifically the most general API; one where you may never even join the thread at all, hence its type signature requiring a 'static bound. Rust doesn't suddenly go "oh you're not actually using the full power this signature gives you, so I'll allow it," because that would make the code extremely fragile, be tough to implement, all sorts of things. Really, this is about using the API that communicates the semantic you want, so that the compiler can check it.
That comes from the undecidability of any interesting property in Turing complete code. It means that if you are doing static analysis on your code, you have to decide if you are going with false errors or mark bad code a correct, because no analysis can always give you the correct result.
The compiler could have a special case for looking at joins. But that's extra complexity that gets you almost nothing in return. Instead, Rust developers decided that it's better to do it in a library and created the scoped thread the article talks about.