One of my clients has started using a automated security scanning tool to regularly crawl their Drupal site looking for vulnerabilities. In their first run of the tool, it identified only one issue: a "predictable resource location" vulnerability based on the presence of the web.config file in the Drupal docroot. Since web.config is used for IIS servers and they're not on IIS, the presence of the file isn't really a security issue for them but, if the scanner is going to complain, it's easy enough to remove it from the code base. The web.config file is commonly flagged by such scanners and just as commonly removed from the code base.
What I hadn't considered before is an idea proposed by the client's tech lead: monitoring access attempts for the web.config file as a honeypot for malicious traffic. Since they're not using IIS, any access of that file may well indicate a drive-by vulnerability scanner. Obviously what you do in response to it could be complicated and you wouldn't want to automatically block the IP or something, but flagging the IP for investigation is reasonable and easy enough to do, especially if you're using a log monitoring tool like Sumologic where you can set up automatic alerts.
Personally, though, I think it's more maintainable to add a deny rule for it in the .htaccess file. That way, you don't have to remove the file again each time you update core, you have to merge your .htaccess which often has custom rules anyway. A simple rewrite rule like the one below does the trick
RewriteRule ^/?web\.config$ - [F,L]