no title
"What reason do we have to think anyone inside the company would do something as nefarious as this?"
You mentioned that exploits of the urchin.js file could prove especially effective when combined with network or browser attacks, yet come back to the attack relying on someone inside google. It doesn't.
Network attacks could include attacks on the DNS system, pointing google-analytics.com to the attackers machine from which they serve up their own urchin.js file. From what I can see at google-analytics.com, google like to redirect pretty much everything on that domain to a google.com/analytics/xxxxxx address. If they do the same thing for those viewing their own stats (I don't use it), chances are such an attack would go unnoticed for days or weeks as the only thing being pulled from that domain would be javascript files which nobody looks at.
Browser attacks could include attacks against the host machine as well as the browser, altering the DNS server settings or the hosts file to point to the attackers address for google-analytics. The result would be the same, in that the attacker has control over what your browser thinks is google code.
Such attacks are made much easier when there is no ssl in use to pull the js code, as there are no warnings about invalid certificates.
Even el Reg has a flaw where SSL is concerned with analytics. http://www.theregister.co.uk/Design/javascript/_.js contains this line:
var s='<script type="text/javascript"'; return s+' src="'+ (document.location.protocol == "https:"?"https://ssl" :"http://www") + '.google-analytics.com/ga.js"></script>'
What this line translates to is: if the visitor is at http://www.theregister.co.uk then pull ga.js from google over plain http. Only pull it over https if they are visiting https://www.theregister.co.uk As long as thereg doesn't actually have a https version, then this line is useless. All visitors will receive the script from google over plain http.
"Where the four disagree was how easy it would be for Obama insiders or others to identify a plot as sinister as a rogue urchin.js"
As AC already pointed out, it's possible to hide a rogue file with referer header checks, and other tricks. When I've done security demonstrations using XSS in the past, a favourite was to return the rogue file to an IP address only once. It's likely that anyone attempting to view the rogue file will have already visited the page at least once, so the only thing they see upon accessing it again is a perfectly innocent file.
Such tricks may cut down on the return you get from the exploit (blocked referer headers, machines behind a NAT IP etc), but they keep the thing hidden for longer. If you get every password on the site but it's noticed instantly and passwords are changed, it's done you no good. If you get 75% of the passwords over 3 weeks and those passwords are not changed, you can work on getting the other 25% at your leisure from the inside.