Burp Scanner divides the checks it performs into active and passive checks. With active checks, Burp sends various crafted requests to the application, derived from the base request, and analyses the resulting responses looking for vulnerable behaviour. With passive checks, Burp doesn't send any new requests of its own - it merely analyses the contents of the base request and response, and deduces vulnerabilities from those.
There are numerous issues which can be identified using solely passive techniques, including:
Clear-text submission of passwords.
Insecure cookie attributes, like missing HttpOnly and secure flags.
Liberal cookie scope.
Cross-domain script includes and Referer leakage.
Forms with autocomplete enabled.
Caching of SSL-protected content.
Submitted passwords returned in later responses.
Insecure transmission of session tokens.
Leakage of information like internal IP addresses, email addresses, stack traces, etc.
Insecure ViewState configuration.
Ambiguous, incomplete, incorrect or non-standard Content-type directives.
Burp checks passively for all of these issues, and more. Many of them are relatively unexciting, and recording them is pretty dull and repetitive for a human. But as penetration testers we are obliged to report them. Having an automated tool to reliably mop up these issues as you browse an application is a time and sanity saver. (By the way, if you don't think your clients need these kind of low-rent issues reported to them, then read this.)
Being able to carry out passive-only vulnerability scans is beneficial in a range of situations. Passive scans won't send any new requests to the application. If you are testing a critical production application, you may want total control of every request that you send. You don't want an automated scanner running amok and knocking things over. So you can use passive scanning to pick up a wide range of issues, while probing manually for those that require active interaction with the application.
Similarly, some applications are aggressive in reacting to attacks, by terminating your session or locking your account every time an apparently malicious request is received. In this situation, you may be restricted to piecemeal manual testing, but you can still use passive scanning to pick up a number of issues without causing any problems.
Finally, if you don't (yet) have authorisation to attack a target, you can use passive scanning to identify vulnerabilities purely by browsing the application as a normal user. For example, if you are proposing for a new penetration testing engagement, then knowing in advance that you already have a dozen reportable issues in the bag can give you some comfort that you won't be looking into a bare cupboard when you start the work.