This is true for lower-level cryptography libraries like OpenSSL or Libsodium. This isn't true, however, for the sort of higher-level libraries I recommend developers use.
See https://github.com/defuse/php-encryption which implements version tagging in its ciphertext output.
If Taylor Hornby has to publish a version 3 that uses, say, NORX instead of AES-256-CTR+HMAC-SHA256, the first 4 bytes will identify the version of the library that was used to encrypt the original message. Backwards compatibility is transparent to the end user. (Headers are covered by the HMAC.)
The first is that some crypto primitives, whether you want them to or not, have implicit defaults. For instance, when enciphering data with a block cipher, ECB is an implied default.
More importantly, even if you require options, the characteristics of the different choices can push developers towards insecure implied defaults. Even in a library that forces you to pick a block cipher mode, for instance, developers have a strong tendency to pick ECB because it doesn't require an IV (and very few developers understand the concept of an IV).
I generally think RSA libraries should default to OAEP.
The argument (no pun intended) for default parameters would be to provide a reasonable value for library users who do not have the expertise to select the parameter value themselves.
The problem with this is that if someday the expert opinion on what the default value should be changes, then the library is in an unfortunate position.
If they update the library to match the newer expert opinion, it breaks existing code. If they do not update the library, then new applications using it will get the bad default value. Maybe they can leave the default alone, but make the library generate a warning that the default is no longer good and the application should be updated to explicitly pick a better value.
If the library had not supplied a default value, then all users of the library would have to make a choice. The library documentation could suggest what choice is considered best at the time, but make the programmer actually say it in the code. That way, if expert opinion changes, the recommendation can change and at least new users of the library might use the better value.