There's a small mistake in the article:
All that this PTS module needs to know is the starting and end points that return a different state, an accessible repository (Git, currently) to be tested to be tested,
Although as others have said, it's the write cache in the disk that's the problem so only hard power-loss can cause the corruption that this change prevents. If you have a UPS, you can run with nobarrier. Linux crashing won't stop the disk from performing the buffered writes. (at least AFAIK. Is that true even if the crash causes a machine reset? i.e. on typical x86 hardware, does the system reset signal do anything that could flush the write buffer in a SATA hard drive?)
If Linux just locks up and stops sending SATA commands, you're fine, because the disk will finish processing its queue.
if te kernel goes haywire it may just stop sending commands, or it may lock up the SATA bus (or send garbage to the drive)
but you are absolutly right that if you want good database performance you need battery backed cache, a 7200 rpm drive can only do ~160 seperate writes/sec, anytime you get numbers much higher than that you are seeing buffering take place, and if you don't have a battery on that buffer it means that a power failure could end up with things written in the wrong order, which may not be recoverable.