A software system without down migrations is a conceptually simpler system, and the lack of (the perception of) a safety net makes one think carefully about their approach to database refactors. So long as they don't then avoid the inevitable database refactors, I surmise this can lead to a healthy code practice.
StackOverflow cannot rollback
Spiritually, they can rollback because if they made a mistake in a database migration, they can push a new migration to fix it, a "roll forward". Here is a quote from Nick Craver on how StackOverflow deployed code
The tooling has no concept of rollback though. Why roll back when you can roll forward?
Earlier on in the same paragraph, he mentions how he can't remember ever doing a rollback at StackOverflow (given his claim that the tooling doesn't support it to begin with, I assume this means they haven't every rolled back "conceptually speaking", aka, done a roll-forward. In my experience of years of professional software development, I also have no memory of every performing a rollback. It makes sense to fear a bad migration, since data is the unshakeable truth of all software. But, also, in every other situation, code that never gets used gets deleted, and code that never will be used should never have been written.
I'm not going out of my way to build systems that have up-only migration strategies, nor am I suggesting you do so. But, speaking for myself, if I'm in a situation where the migration strategy is yet to be determined, I think I will advocate for an up-only migration strategy.