Not at all. "don't roll your own crypto" is a downside that can lead to things completely falling apart or weakening the system overall.

The real downside is that there's a better, proven way to do the same effective thing, which is make a database-only compromise require additional work, without rolling your own crypto. It also supports doing things retroactively for real (not some of the hacks being discussed in this thread) and key-rotation. All the upsides, with none of the downsides.

> "don't roll your own crypto". I think they are negligible

Please do not ever consider "rolling your own crypto" a walk in the park. Unless you have a serious security background and some actual cryptography education and research never, never, NEVER do this. It is not negligible, and it is not safe.

The fact that the pepper can't be changed/rotated far outweighs any upsides

You can change your pepper by double-peppering your existing password database:

  scrypt(scrypt(scrypt(scrypt(password, salt), pepper2013), pepper2014), pepper2015)

https://blog.filippo.io/salt-and-pepper/

Sounds like a maintenance nightmare. Need to ensure you keep your tongue straight when partitioning or restoring databases, migrating/splitting to new apps etc.

You consider "not maintainable" to be an acceptable downside to _anything_ you're doing with your software? What?

I wouldn't say negligible, but rather not slam-dunk convincing