> 2) or this guy used commands that passed the password as an argument (for example "curl -u username:password" maybe svn has something similar?)
Other commands that take password arguments include ldapsearch/ldapmodify/etc (-w argument), mysql (-p/--password option), and Oracle sqlplus (sqlplus user/password@db)
Best practice is that you don't put passwords in command line arguments, and find an alternative method of supplying the password to the utility (such as reading it from a password file, or using non-password-based authentication mechanisms such as Kerberos). Despite that best practice, I'm sure plenty of people still do it.
People also sometimes accidentally paste passwords from a password manager into their shell and they end up in their shell history. This can easily happen if you are meaning to paste it into some kind of interactive command such as ssh or su and the command doesn't execute the way you expected.
If you discover you have passwords in your bash history, editing it to remove them (or even deleting it entirely) is a sensible thing to do.
Shell history was never meant to be an auditing measure. There are products out there that will record SSH sessions (by acting as a recording proxy between the client and the server); if you need a list of commands executed for auditing purposes, those sort of products are the proper answer, not expecting people's shell history to be left intact.