The difference is that because we're using Rainforest in our build process we cannot deploy if Rainforest itself doesn't work... so it's a bit more 'extreme' than regular dogfooding.
Then I guess we used "extreme dogfooding" with our travel company. We colocated other roles with our offshore developers and we used our own site (http://AllTheRooms.com) to find accommodations for designers and product managers who traveled to be with the devs in Medellin, Colombia.
So, if the site didn't work it would have been pretty painful not having a place to stay.
In regular dogfooding, you would give up if your product was so bad it prevented you from working on anything. I think the extreme here means they are trying to make failures as painful for themselves as possible, even if doing so makes it harder to resolve those failures.
It's probably instructive to think about the type of product that you'd be dogfooding.
For most startups, dogfooding is a process of heavily using your own product to figure out what works and what doesn't and better understand the painpoints in the product from your customer's perspective.
That process changes quite significantly - what we're calling 'extreme' dogfooding - when the product you are dogfooding is a crucial part of your build process, because you cannot deploy if the product isn't working properly, whereas with most products that aren't developer tools a problem found through dogfooding isn't going to do something as drastic as preventing your deploy :)
The nature of your product means that you are able to use the product as part of creating the product. Much like how a trucking company uses its own trucks to deliver the parts needed to build/repair those same trucks. Or how gcc is used to build gcc. What you call "extreme dogfooding" is more like half plain old dogfooding and half bootstrapping.