They allow you to do much more. You can see this put to use in the Rocket project quite heavily. I believe it should be possible to link against bindgen as described and generate the bindings inline.
The caveat here is that it would be fairly opaque to the user as you wouldn't see the generated bindings in code. For situations like that I rely on 'cargo doc' to generate the documentation such that I can see the actual interface generated.
Rocket codegen for example: https://github.com/SergioBenitez/Rocket/tree/master/codegen
So it means that even if Rust had a standard C header include directive it still wouldn't be completely transparent because most of the time you want to wrap around C APIs in Rust to provide safe, borrow checked and pointer-free alternatives. There's a different philosophy I think.
Bindgen is often invoked in a "build script", which Cargo runs before building your project. So not exactly, but basically.
If you look at the Python vs. Lua C API you can see that difference. Lua was designed to interoperate with C (albeit after breaking the language 4+ times); Python just took whatever their implementation happened to be, and then exposed that API to users. With thousands of functions and macros and GIL and whatnot.
Then a bunch of people came along later and wrote 5 different binding generators, and all of them solved some the problem, but not all of the problem. And some of them created new problems (SWIG).
Also (to child comment), is it really possible to do bindgen as a macro rather than as a separate code generating tool? Because I assume bindgen has to invoke a C++ parser like Clang.
I looked at Zig and it indeed uses libclang to parse C. I don't know about Rust's macro system but it would be somewhat surprising if it can invoke external tools or run C++ code at compile time.