Some of the APIs in use on Linux today come from older Unix variants. (For this reason, I probably wouldn't call one of these a "Linux API" as the author did, though I guess it works linguistically for those that are usually present on Linux.) These APIs have semantics that were designed before threading existed on many platforms. Making them thread-safe without breaking existing code can be challenging.

If setenv(3) is among these, it could explain why glibc's implementation doesn't support multi-threaded programs, and why its documentation states as much. To have used it in a multi-threaded environment, ignoring the docs, was a bug in the Steam client. Perhaps it never occurred to the people who ported Steam's code to glibc that threading issues might be different from what they were used to on other platforms.

To be fair, the author might be aware of this, as he did refer to glibc's implementation as a tradeoff rather than a bug.