The downstream is downstream of the design IMO. In general, people write the API that is obvious. In C, returning a string is obvious, while defining a custom OptionalString type is high friction. In Rust, returning Option<String> is as easy and obvious as returning a String.

In a C function returning a string, two or three idioms are common for signalling an error.

One is to return NULL for errors.

Another is to make the string result a parameter and use a return code to signal error.

A third, less common but still out there, is an error parameter.

Failure to observe these is on the caller. Forcing the caller to consider the error is probably where rust shines.

But a good C programmer is thinking about these idioms when they encounter a function signature for the first time, or they write one.

Sure, you could write deliberately bad code in Rust by unwrapping everything everywhere, but the point is that it is a distinct choice to do so. You can’t forget to handle errors - you have to make the choice to disregard them. If you forget to check for NULL in C it won’t complain and it’s dependent upon you to remember to do so.

Unwrapping everything isn't even bad, that's what most webservers will do

All the standard Rust libs use results. The standard C and C++ libs use errorno, return 0, return -1, return nullptr, maybe exceptions if C++, ...