Not really. It's true for any language where types have statically-shaped memory layouts, and where names are statically bound. Lambdas need to bind their names to locations; if this is to be done statically, then the bound names need to packed into some reference type. The type of the bound name environment cannot be named, because it is dependent on what specifically the environment is naming. Languages that fall into this category would include C, C++, Java, C#, and Rust.

By contrast, languages such as Python or JavaScript that rely on dynamic name binding have implicit environment objects attached to their objects that allow different lambdas to share the same type, since the function body gets to acquire a map that it can ask for the bound names.

> the bound names need to packed into some reference type

Exactly, and that's how we refer to them. We already do the same for arrays–it would be overly pedantic to refuse to call an address/size pair an array because it doesn't actually contain the elements it refers to, just as statically-typed languages with lambdas are actually just passing pointers around. C could do this too–we'd just need sugar that would convert lightweight lambda syntax into code somewhere that would have the same type as a function pointer.