Yes. It always has. The "ZFS needs ECC RAM" meme comes from the fact that on many systems the (non-ecc) RAM is the weakest point in the data integrity path if you are running ZFS.
For an analogy, consider a world where car engines have a non-trivial chance to instantly explode when involved in a crash. Then someone comes out with an engine that doesn't explode. People say "you should wear seatbelts if you use this non-exploding engine," but your car has no seatbelts; clearly you are still safer with the non-exploding engine, but all of the sudden, seatbelts are more likely to save your life than before.
In think the concern is more that if you encounter a bit-flip checksumming a block on write, then ZFS will mark the data corrupt on read; and thus, make good data unreadable.
A non-checksumming FS would not be vulnerable to this particular issue. On the other hand, would undetected corruption through bit rot be a worse problem? Almost certainly.
And considering how vanishingly unlikely such a scenario is, I do agree with your sentiment.
That said, I'm not sure if my understanding of the issue is complete and would welcome an explanation of the failure scenarios that [very] occasional RAM bit-flips expose ZFS to.
It all depends on the relative probability of those two scenarios occurring, though. And the problem with ZFS is that each time you are scrubbing you are essentially rolling the dice, so you are rolling them a lot more times.
Let's say that you have a 99.9% chance of the scrub running correctly on a big pool with non-ECC memory (0.1% chance of a bit-flip during the scrub). Any single scrub is extraordinarily likely to succeed, but if you run a scrub every day then over the course of a year then your chance of your pool surviving falls to 0.999^365 = 69.4%.
Pick your favorite numbers here, 0.1% failure chance per scrub is probably way high. With five nines your yearly survival rate is 99.6%. But do remember that soft errors are fairly rare in modern servers mostly because they use ECC RAM, you can't look at data with ECC and assume you'll get comparable results by using non-ECC RAM.
In general, if you scrub infrequently you are probably going to be OK. (but then why are you using ZFS instead of LVM?) If you live at high altitude, however - let's say in Denver - you are also facing significantly increased soft error rates. The extra atmosphere at sea level does make a strong difference in shielding, something around 5x reduction in strike events.
On the plus side - the SRAM and some parts of the processor do use ECC internally, which is good because fault rates increase with reduced feature size and increased number of transistors. The CPU is potentially the most sensitive part of the system per unit area, so it's very important to protect against errors there.
And on the other hand - disk corruption or failure probably outweigh those kinds of concerns in practice. But it's not like it's expensive to get a system with ECC. An Avoton C2550 runs like $250. So why take the risk anyway? Your data's worth an extra $100 in hardware.
Heck, you can run ECC RAM on the Athlon 5350 and the Asus AM1M-A motherboard. Boom, ECC mobo/CPU combo for under $100. It's just a little thin on SATA channels. It's a shame there's no "server" version of this board with dual NICs, IPMI, and an extra SATA controller tossed on there.
For an analogy, consider a world where car engines have a non-trivial chance to instantly explode when involved in a crash. Then someone comes out with an engine that doesn't explode. People say "you should wear seatbelts if you use this non-exploding engine," but your car has no seatbelts; clearly you are still safer with the non-exploding engine, but all of the sudden, seatbelts are more likely to save your life than before.