I wish you had provided more information here but maybe that was intentional.
The answer is within the question...
The module feature detects for another module, and uses it if
available. Otherwise, it can safely ignore it.
Then it's not a dependency, is it?
Maybe an issue was posted that would not have been posted if the user had taken the time to RTFM. Or maybe had a look at the README file, or maybe the online help. But a module on a dev system can behave behaving differently when enabled on a production system and leave even good people scratching their heads.
You are correct in that best efforts in documentation are often ignored. If something works wonderfully out of the box, very few will read the documentation.
When was the last time you read the instructions for xmas lights?
I have a similar dev story. My module has a page with a configurable url. Before this can be changed, url availability must be checked. Drupal offers a variety of functions for this but the are not consistent across D6, 7 & 8 and some not available at all in D8. All fail under some scenarios.
So I opted to write a small purpose built function that made use of the php cURL library. I thought cURL was a pretty common library (it is) and I did not give this much thought. The purpose built function works in all versions of Drupal without modification.
It did not, however, install with Drush because the drush config did not include cURL. Drush did not, at the time, behave very elegantly either, attempting to repeat the same failed process repeatedly without proper error reporting until it gave up or timed out.
I was developing in Windows at the time and did not use drush. This problem confounded me for a long time because it worked for me and others but did not work for some. Those included people who were performing code reviews needed before my sandbox project could become an official Drupal project.
There were also great objections during the review process to the purpose built function -- why not the Drupal standard API functions available? I finally figured out it was a curl dependency when one reviewer finally mentioned it.
My solution was to to use a series of tests for url availability which started with the Drupal API functions. If all of the Drupal API calls passed, then I used a php function_exists('curl_init') call to detect if the library is installed.
So this now works with a drush install with or without cURL being installed. If cURL is installed, it works better, catching that use case that the Drupal API misses altogether.
This is not a dependency, it's a serendipity. (forgive the grammar)
Will I make it a dependency (how is that done?) or implement hook_requirement()? NO WAY. It is not necessary.
Of course this does not deal with the issue of unexpected different behaviour that a serendipity might toss in the face of an admin who was previously delighted with those new xmas lights.
After reading your question and giving it some thought, I reckon I will take this approach:
In the soon-to-be-released 1.0 versions, there will be a message that appears on the admin config screen, in bold colors, announcing that This module will work better with the cURL library installed.
And this message will only appear if the cURL library is NOT installed. I figure that this will be the edge case. Who cares otherwise?
Enjoy your xmas lights.