Sure, if you are putting in a health check and nothing else, that's fine. When you need to parse headers, negotiate content types, validate maximum lengths on requests, properly log the source of the request (it's not just the connecting IP if there's a load balancer in front of it), parsing request bodies, dealing with range requests, authentication, cookies, providing a good middleware mechanism...
The list goes on. While I'm not a Rust developer, there's probably hundreds of libraries because the problem is structured into a lot of small parts, and frameworks are expected to be able to satisfy the functionality you expect without needing to bypass it.
As a security engineer it is still usually cheaper to write specific functions I need for highly limited scope applications than pull in libraries I have to review, and review every update to, forever.
I've seen this attitude before. In that specific case, someone tried to not depend on the signal_hook crate and manually (unsafely) implement signal handling… without knowing that there's a ton of pitfalls to it.
The person you are referring to was likely also me. I do not know of anyone other than me trying to code defensively against supply chain attacks in rust. It is a lonely corner.
I ended up going with sigwaitinfo since the attempts you likely saw on matrix which is perfect for my application that will only ever run on modern linux kernels.
Combining that with the stdlib health check above and we end up with a dead simple health checking signal handling service pattern that works well and easy to confirm is free of supply chain attacks.
The list goes on. While I'm not a Rust developer, there's probably hundreds of libraries because the problem is structured into a lot of small parts, and frameworks are expected to be able to satisfy the functionality you expect without needing to bypass it.