It was more the opposite IME (90s-era linux): fsck after a crash was boring and time-consuming, and we grew increasingly impatient as capacities grew.
Prior to having a journaling filesystem and log replay @ reboot/mount, the filesystem was often plain conservatively implemented using methods like two-phase-commits and arguably kept more consistent due to the repeated exhaustive checking process at every dirty mount.
We went through a phase of putting a lot of trust into the hardware keeping things consistent/no-bitrot and more or less assuming everything was fine after a journal replay. Only relatively recently did we start getting checksums of metadata to detect such failures, that's still not a universal feature.
The lack of frequent fscks creates opportunity for hidden corruption from either bugs or hardware errors to go unnoticed until it's far too late to recover from... There's a reason filesystems tend to have a max mount count before a fsck is forced, even if not dirty.
Scrubs / checks / etc for online consistency check.
Journaling did take off in a big way, with NTFS, HFS+, ext3, etc. supporting it. This mostly removed the long fsck on most modern operating systems.
Of course, traditional filesystems + journaling are now rapidly being replaced by CoW filesystems.
I later manually did the needful to get XFS working as it was faster on deletes, iirc.
https://www.usenix.org/system/files/atc19-jaffer.pdf
It may have improved since then, who knows.
Log-structured and CoW are very closely related.