The other answers so far are all terrific. I'll reiterate one point, and make a new one:

* The openness of an API is always important, but when complete, quality bulk data is available some of these access issues become a lot more tolerable. **An API is [not](http://sunlightfoundation.com/blog/2012/03/21/government-do-you-really-need-an-api/) a [substitute](http://www.peterkrantz.com/2012/publishing-open-data-api-design/) for bulk data**. The federal government has become very API focused, and many of them have throttling, API key registration, and even [attribution](http://www.eia.gov/beta/api/tos.cfm) requirements. The need for accompanying, complete bulk data is a point I hope the community will continue to press.

* There's an important political aspect to API key registration, which is demonstrating (especially internally) that the API is a success, and worth continued investment. I work at the [Sunlight Foundation](http://sunlightfoundation.com/), and this is one of the reasons (in addition to abuse, contacting devs, etc.) we require registration of an API key. This is both quantitative (measuring hits), and qualitative (it's nice to have logos of big organizations [on the sidebar of our API homepage](http://sunlightfoundation.com/api/)).

Of course, government agencies are in a fundamentally different situation than non-governmental organizations. They're funded directly by taxpayers and are the original producers of information that literally belongs to the public. 

When agencies consider the benefits of using API keys versus providing open access, the scale should be heavily tilted towards open access to the people's information. Providing free bulk data access in addition to any APIs (like the [Census does](http://www2.census.gov/)), and providing key-free API access (like the [Federal Register does](https://www.federalregister.gov/learn/developers)) are models I strongly encourage.

**Update**: See FederalRegister.gov's [API case study](https://www.federalregister.gov/uploads/2012/11/FR2-API-Case-Study1.pdf) for their rationale for not using API keys:

> In our view, API keys can create an unnecessary barrier to rapid experimentation with our public data. We are able to track our API usage via logging mechanisms on our servers and already have infrastructure in place to mitigate any sort of excessive requests. The benefits of using a simple REST-ful API format are that any user can easily try it in their browser (no SOAP that requires complicated XML to be POSTed around, no special headers, etc). The response to our no keys policy from the development community has been extremely positive (http://news.ycombinator.com/item?id=2839137).