While I do not disagree with you, I still do think that even these cases mutexes and conditions are more practical.

Take the "rate limiting" example you mention (also one of Linus' examples in the OP). You initialize a semaphore to `max_concurrent_connections` and call `semaphore_down()` when you enter the connection handling sequence and `semaphore_up()` when you're done. Now this works fine and is an idiomatic example of using semaphores.

However, in the real world, this kind of situation rarely happens in isolation. What happens if you need to terminate the application for whatever reason, and do so cleanly? If you're under contention, you might have a dozen threads waiting for the semaphore go up and your only option is to kill them. Or implement some logic for this case (using another semaphore) to make sure the application hasn't been terminated while we were waiting for the rate limiting semaphore.

You can implement this cleanly using mutexes and conditions, by creating a "killable semaphore" synchronization primitive. While this is similar to a semaphore as an idea, it's very difficult to implement it if semaphores are the only primitive you have. Additionally, you probably want some kind of timeout if the queue is full.

So in practice you need something like:

    while(true) {
        socket = accept();
        int status = rate_limiting_enter(my_rate_limiter);
        // NOTE: someone else may call rate_limiting_terminate()
        if(status == OK) {
            service(socket);
            rate_limiting_leave(my_rate_limiter);
        } else if(status == TIMEOUT) {
            send_busy(socket);
        } else if(status == KILLED) {
            send_terminate(socket);
            break;
        }

        close(socket); // this must be called or resources leak
    }

Now, while this is theoretically very similar to a semaphore, it has other real world priorities (like timeout and termination) which are very difficult to implement using Dijkstra -style semaphores with only P() and V() operations (and you definitely need more than one semaphore).

This has been the case in almost every practical multithreaded programming scenario I've had. The solution could be thought of using semaphores (and I frequently do) but in practice, there's always some real world conditions (timing, contention, errors) that must be met.

It is very trivial to implement semaphore-like synchronization primitives using mutexes and conditions but not vice versa.

Semaphores are very good for textbook examples and a mental model but not so much in practical software.

Termination in queued systems is moderately hard. You have to drain out the queues. In Go, you can close a channel at the write end and wait for the reader to reach EOF. But if the reader is stuck waiting for something, there's a problem. Especially if it's waiting to write another channel. If you close a channel written by another task, that task will panic when it writes to the closed channel. You can't close channels to force shutdown in Go unless a panic is acceptable.

This is a classic problem with bounded buffers, re-invented four decades later.