I found a way to shrink the monster class by 500 lines or so, which isn't bad. While implementing the rest of the features, I made the following observations:

Observation 1: Some methods are highly specialized and have unidirectional dependencies. For example, the methods for inserting, updating and deleting blog entries require a slew of other methods, but aren't required by any other methods in the class. They essentially act as interfaces to the outside world (i.e. they're what would be declared as public methods in a real OOP language).
Observation 2: Such specialized methods are isolated. For example, the methods responsible for adding/updating/deleting post entries are totally separated from, for example, the methods that add/update/delete links. A PHP page or RPC method that does stuff with post entries will most likely not do anything with links, section, etc.

I was then able to isolate 5 groups of methods that fit the above observations and create child classes to the original (now shrunken) monster class to hold the specialized methods. When instantiating an object, the calling script now has a choice of 6 classes, depending on which functionality is required.