The best way that I can explain it is that the framework (background elements, menus, and the rest of the interface) were all coded in Flash MX Professional. Actionscript 2.0 introduced a new file extention, .as (for Actionscript). The distinction between what is OOP and what is not becomes a lot less distinct when you start working with it, especially in Flash. OOP is just a way to take a set of things which have an existing relationship, give them a name, and formalize that relationship in a way that makes the resulting code cleaner and more efficient. When the application launches, it imports all of the class files, and creates an instance(object) of a class. That class in turn creates other objects. Some of those objects then import symbols from the Flash library, or external XML data, or entire other Flash movies. So the structure which drives the application is essentially all OOP, but the individual pages and elements are not.
Each page of content was first built in InDesign, converted to PDF, then to Illustrator. I know this sounds insane, but InDesign is the best tool for typesetting and page layout by far, and we had a lot of content to put together quickly, that had to also look good. From Illustrator, pages that needed to be interactive (with links) were converted to EPS and then opened in Flash to add links. The links are done with the most basic Actionscript, and are just attached to individual pieces of text within the Flash document. The pages which didn't need links were ripped to .swf format directly from Illustrator.
You can do OOP badly, and end up with classes (a class is the template for an OOP object) that don't really work that well together. You can do it well and end up with a application that is much more efficient than it could ever be as a non- object-oriented program. The thing that takes time and practice and a lot of head scratching is to know when something should be built as a class/object, and when it shouldn't. Someone mentioned the car example earlier. It seems simple. A car is an object. A car has wheels, therefore wheels should be a property of the car object, as should seats, steering wheels, color, make, model, and everything else about the car. A car is easy to think about because it's a concrete object, and something that everyone is familiar with. When you start thinking about more abstract objects - user interfaces, search engines, etc. - you find that it is far less intuitive to decide which elements should and shouldn't be members of a class. When you get to that point, look at design patterns.
I've actually just started trying to work some OOP into my PHP work. So far, I haven't found that much info on the subject. That's why I would recommend looking at Flash to start with. There's a lot more information out there.
Incidentally, my web site does not mix Flash with PHP. The web site is all PHP, Javascript, and HTML. Javascript actually does all of the work for the menus and the user interface. PHP is used mainly to pull info from MySQL and write it into the page. The only Flash is in the 2-3 portfolio pieces that use it.