First of all, thank you very much for your detailed answer!

I think you are right about your three points.
[1] The parameter/variable names are changed to hyphen conventional symbol names.
[2] I have refactored the example test to be (hopefully) much clearer.
[3] Invalid input values are now ignored.

By the way: I also took this opportunity to add a random test.

I really liked this kata, I don't really know why the low satisfaction rating, but I can guess[1].

Issue:

Expected #f, but instead got #f
This was posted as an issue last year but still an issue today.

Suggestions:

[1] I think the description overcomplicates the kata and that's why it is marked as a low satisfaction rate.
You can use longer names as variables/parameters, which is, as far as I know, a good practice in Lisp, instead of using "v_r", "v_s", etc.
They're not even in the most accepted style used in Lisp which is to use hyphen conventional symbol names instead of underscore.
I don't think the extra-work and confusion about the symbol names worth and it doesn't add any value to the kata description or to the practice or learning, specially considering a 8 Kyu kata.
But hey, that's only my opinion.

[2](check-= (swim-distance 10 5 5) 11.1803 0.001))
This is also a question. I don't know the implementation of check-=, Why do the 0.001 as a parameter?
For a good moment I was totally confused about what I should return, as the description said to return the distance but there was more parameters in the test case.
Although as they're not as a list I should have just guessed the 0.001 was not relevant to test my solution, but still, since looking at the test and writing your own tests is part of how codewars is used, I think the test function should be improved to be easier understood and read.

[3]In case of invalid input values (e.g. negative river width) the function should return 0.
A negative river width is conceptually an invalid input value, but not practically, the tests will always pass and this is everything I can say without spoiling the solution.
Also, in my humble opinion, the cases where the swimmer velocity is zero and the river width is zero should be stated in the description instead of the wrongly stated (and irrelevant) negative river width case.
It's lame to have to fail just to see that you need to implement those two easy test cases...
This is again a problem of lacking of description.

In general I liked this kata a lot. As simple as it is, I liked it more than the majority of katas I've done in codewars so far.
But I think the lack of clarity in the description doesn't add value to the kata. You can just make a clear description and if you think people will solve the problem too easily, think that it is a 8 Kyu kata, it should be easy anyways.

Good point. I changed it.

For the answer template, typical Racket practice is to use the short form for defining functions

(define (my-func arg1 arg2 arg3)
 ...)

rather than the lambda function form of

(define myfunc
  (lambda (arg1 arg2 arg3)
    ...))

Changing the expected result to 0 makes even less sense, and it's still not indicated in the description what should be returned.

Also a good hint. I add messages to the test cases.

Yes, that is a good point. When the swimmer dose not move, he can not swim any distance.
I adapt the kata.

Zero swim speed

This case is absurd anyway, and there are no indications what should be returned in this case.

Expected #f, but instead got #f

The values are not displayed properly in test messages.