It has become increasingly common for newspapers to limit free access to their content. Both the New York Times and the LA Times restrict the number of articles that you can read each month unless you're a paying subscriber. This being the Internet, people immediately began looking for ways to defeat the limit. There are a couple of different ways to do it (they're widely known, so I don't feel like I'm costing either paper anything). One is to periodically delete all of the cookies the sites have stored with your browser. Another is to keep your browser from running scripts from those sites.
Based on what we know about blocking the check, there are two parts. First, each time you download an article, a "cookie" comes with it. A cookie is just a chunk of data that your browser stores. In this particular cookie is a count of how many articles you've downloaded this month. Whenever you make a request to the site that sent you the cookie, a copy of the cookie goes to the server as part of your request. The Times' server increments the article count in the cookie and sends it back. From what we know, the Times' server does not do the actual blocking; it just increments the article count. As part of the article download, the Times also sends along a script -- a piece of code that your browser executes. The script checks the article count in the cookie and blocks the display of the article if the count is too high. We also know that if the cookie doesn't exist, the Times sends back a cookie with a count of zero.
Why implement the limit check in this fashion? It makes things easier for the Times because all of the hard work is being done on your computer, not on their server. For every request, the Times' server gets to do the same thing: increment the cookie counter, creating a new cookie if necessary, and download the requested page plus updated cookie plus script. No checking against the database to see if you're a subscriber. No generating a different sort of response. This makes the server simpler, faster, and (IMO probably the deciding factor) cheaper. It also makes it easy to defeat the limit: either delete the Times' cookies periodically or refuse to allow the script to run. Deleting the cookie in order to defeat the limit does raise an ethical question (I'm intentionally taking action in order to read articles that the owner hasn't given me "permission" to read). Keeping the script from running is more problematic.
There are good reasons to block scripts. Scripts can find a lot of personal information about you and send it off to the bad guys. In extreme cases, scripts can mess with your computer in bad ways. Security advisers often recommend blocking script execution generally (the University of California at Santa Cruz guidelines for campus users is an example of such a recommendation). If a person has blocked scripts, the Times' limit on the number of articles that can be viewed is defeated. If a person were running the Firefox browser, with the NoScript add-in blocking execution of scripts, the Times turning on their article limit would have been a total non-event. That person's perception of the Times' site would have been exactly the same after the limit was turned on as it was before the limit. In effect, the Times is asking readers to operate their browser in an insecure fashion so that the Times can implement article limits cheaply.
The Times is essentially saying, "We're going to put articles up in a public place. We request that you only read ten articles per month without buying a subscription. We want you to remember your count and stop at the appropriate time. We're going to count everything you read, no matter how trivial, no matter how you got there (including following bad links we provide), against the limit. And we're not going to make a serious effort to keep you from reading past the limit." That's not a business arrangement, that's a request for contributions.