Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:

• HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.

• PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
  Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
  File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
  NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.

• OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
  Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.

• TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
  Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.

• One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.

Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:

• HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.

• PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
  Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
  File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
  NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.

• OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
  Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.
  NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".

• TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
  Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.

• One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.