You're missing the important part:
Funny thing - if RSA1024 is more than enough to secure my bank transactions, why wouldn't I trust it with my DNS queries?
In order to break your bank transactions, someone not only needs to break RSA, they also need to break TCP, and quickly, I might add.
Without TCP, RSA becomes significantly weaker, no longer requiring a billion dollar machine to break very small messages- if you're trying to spoof an IP address, you only need to attack four bytes; a differential attack could special case keys for less still.
TCP is rarely broken; people rarely have their POP3 passwords sniffed, and rarely have those connections hijacked, and in the absence of a lan-based attack, the practical probability becomes almost nil.
Breaking TCP is hard because not only do you have to break the sequence numbers, you also need to break route filters, and possibly more; Part of HTTPS's practical security comes from the fact that breaking HTTP's unintentional security is hard as is- a single short-lived message over a dozen messages, spanning a second, is much harder to break than a RSA-signed DNS packet, which might be valid for days- or even weeks.
LAN-based attacks (hacking a router, spoofing ARP, sniffing wireless, splicing cables) are impractical for most attacks; we generally only see them for extremely targetted attacks. It seems reckless and naive to optimize for this case, when DNSSEC only seems able to do it by making the practical and likely attacks easier.