Here are a few major differences intranets and regular web sites:

You raise some good points, a few of which I'll take issue with:

Your target audience is going to use the intranet regularly ... This means you can create a denser interface that doesn't hold people by the hand.

We're venturing into web applications here, and to that extent you're correct. Applications that people use on a frequent basis can have denser interfaces. And you can deploy web applications on an intranet. I consider them separate but related beasts.

You don't have to market to your intranet users.

You may not have to sell to your intranet users, but you certainly have to market to them. Marketing is about letting people know what's there, and how it's useful to them. The email you get from HR reminding you that policy manuals are available on-line is a form of marketing. A sidebar on a main portal page listing key things that are new is marketing.

By knowing up-front exactly which platforms you have to support you'll save huge amounts of time debugging cross-browser issues.

True, though there always seems to be some fanatic who insists on running Netscape 4.7. :(

Web sites don't typically allow their users to post primary content, but intranets should, so you must standardize heavily. Don't let it turn into a ransom note of 250 different styles. Don't even allow for the possibility of someone breaking your standards for information structure - that's a huge usability hit.

Let's separate the points:

First, many web sites let you post primary content. We're in one right now.

The other point is whether having one consistent architecture and style maximizes usability. I don't agree that it does. While it's tempting imagine how wonderfully consistent and usable the world (or an intranet) would be if there were centralized control over style and meta-content (information structure), these impose a substantial hurdle on getting information out. In my experience, it's more important to get information out, even if it doesn't fit into an overriding structure. For big, semi-static entities like Human Resources, a common information structure makes sense. But for dynamic teams, I'd much rather let each choose whether they want to use some common mechanism, or whether they prefer to set up their own Slash/Everything engine, or even use MoveableType. Add some variety into the gene pool, and let natural selection do its thing. Starting off with a grand design is a form of premature optimization.