Why should the OPTIONS method not be allowed on an HTTP server?
An essential part of security is to reduce the attack surface by removing any functionality which is not needed. Usually this is also functionality which is less well tested and thus might be a vector for unexpected attacks. For example there might be restrictions/authorizations in the web application which are specific for GET, POST and which ignore any other methods. On the other hand part of the applications code might ignore the request method and thus access to protected resources might be possible using unprotected request methods. Thus removing OPTIONS, HEAD, TRACE etc makes sense in case these are not used.
But, OPTIONS might be needed in connection with CORS to allow cross origin requests. In this case removing it would impact functionality and thus it should not be removed.
In general it is a bad idea to just black list request methods which might be a problem. Instead white listing should be done, i.e. only allow request methods which are known to be handled properly by the application.
Others have pointed out that you want to limit your attack surface, and to be aware that some Ajax sites legitimately use OPTIONS. Anyway, I wanted to share a recent experience with you.
We had tested a site and discovered it was vulnerable to executable file upload. Roughly speaking, you could upload a JSP file as your profile picture, then execute the JSP file and take control of the server.
The client's first attempt at a fix blocked fetching the JSP with a GET request. However, we discovered it was still possible to execute the JSP using an OPTIONS request. You don't get the JSP output - but it's easy to code the JSP to connect back with an out-of-band mechanism.
In this case, allowing OPTIONS allowed a remote server compromise.
R commented that it's not OPTIONS at fault. That is true, it's poor coding at fault. However, if OPTIONS had been blanket disabled as a defence in depth measure, then this site would not have been exploitable.