I think the whole NSE system serves to boost the signal-to-noise ratio of Nmap scans. Most scripts will avoid producing output if they have no useful information. If you're talking about vulnerability discovery, then any of the scripts in the "vuln" category will be useful. A couple points of clarification that may help you use Nmap and NSE more effectively:
Many scripts will not run properly if version detection (
-sV) is not performed first. Version detection provides extra information that is used by NSE to determine whether to run a script on a particular host or port.
-sV will run all the scripts in the "version" category. Scripts, even in other categories, can also update version information. The two systems are complementary.
-sV is too verbose, consider saving your results in XML format (
-oA) and using a results viewer like Zenmap, Martin Swende's onepage result viewer, or even your web browser (with XSL support) to drill down to the information you want.
Scanning all 65536 ports (yes, 0 is a valid port number!) is usually overkill, especially with version detection. If you are doing this for assurance of network state, consider setting up a periodic scan (just ports) and using Ndiff to see changes. You can choose to do a more thorough version detection scan of any new ports that show up. For general network discovery, the top 1000 ports (default) are usually plenty to check.
It's important to note that lots of scripts will not run by default, even when requesting a script scan (
-sC). This can be because they require more input (via
--script-args) to run (xmpp-info), or because they are not considered "safe" enough or they are too verbose or slow to run by default. An example would be ssl-enum-ciphers, which used to be very time-consuming to run. I spent some time increasing its efficiency, but it still is too "intrusive" to be in the "default" category. Reading through the NSE documentation portal (or at least searching for scripts that apply to a particular service) can yield some real gems.