An external journal isn't the same thing as an LVM cache device at all. An LVM cache on an SSD for writeback wouldn't be volatile, so the concerns with data integrity aren't enormous (except for if that cache device(s) were to suddenly fail - and this cache device can actually be a RAID in of itself via Linux MD or similar).
An EXT4 intent journal consists of many small writes that benefit from a fast low-latency storage device, be it external or the same device that data is stored on. When using rotational media for data disks, this becomes relevant in highly random and transnational workloads.
A writeback cache coalesces writes together so writes are for the most part sequential but makes no distinction between data and metadata, or of the journal in particular. It will stand in front of all writes, caching everything and then queuing writes to the disk in as sequential a manner as possible during a flush given the cached data set. Flush commands are sent at the same time as write barrier commands (at a given interval), ensuring a non-corrupt state on its backing device.
If a writeback cache suddenly and completely dies, you will lose some time on your filesystem but it will still be consistent. (EDIT: this statement is directly disputed in the comments below which warn of severe filesystem corruption.) This can be mitigated with a RAID1 cache device.
If a journal device dies, you will be unable to mount your filesystem until discarding the journal device using
# tune2fs -O ^has_journal /path/to/ext4device. In this case, you would have to repair this filesystem with a full fsck scan (which in some cases would take a LOT of time). You would also likely see corruption if this happened during or before a power loss.