I have long had it at the back of my mind to create some documentation of a high-level, diagrammatic/conceptual nature, describing how things are supposed to work together in the software. We have a lot of documentation of details (e.g. how the code works in close-up detail, what the various different methods and functions do) but not a great deal to explain the bigger picture.
For example, I have thought about creating some diagrams that explain, briefly and simply and on a conceptual level, how the state machine classes I wrote are supposed to be used to build arbitrary state machines, because that is something I would personally find useful if I was coming in as an outsider. It's all very well having the classes documented in the way that they already are, but if you have missed the basic concept that they implement, then reading the class documentation might not get you very far.
I also thought about doing a block diagram or two that just outline the main components of the software system, their responsibilities and how they fit together; at a higher level than classes. i.e. framework vs. logic, database, web GUI, and the manner in which they are interfaced with one another. Currently this is not at all obvious when you are coming in fresh as an outsider, and it takes quite a bit of reading the source code and documentation to figure it out. (At least, that was my experience.) So, such a diagram would be an aid to quickly grasping the big picture and then zoning in on the relevant component. It would be akin to a class diagram, so it wouldn't show every instance individually or get bogged down in details.
Alas, I have been very short of free time lately, so it would be unwise of me to make promises of diagrams at this precise point in time.
I think a glossary of terms could potentially be useful, and would fill some of the same gaps as my proposed block diagram, but the risk does exist of defining terms for the sake of it. Perhaps you can devise some kind of criteria to decide whether a term is important enough and sufficiently non-obvious to put in the glossary.
Class diagrams tend to be at least marginally useful if you already have them, but in my opinion the effort required to create them and keep them up-to-date is not necessarily commensurate with the benefit of having them to hand. I think it is worth being selective about which classes to show and in what level of detail. We already have documentation for the methods and properties of classes, so I would suggest diagramming primarily just the relationships between the classes, to avoid duplicated work.
I'm not sure what the object diagrams and flow diagrams would be used for, but they might be useful. I think I'd need an example to understand what you intend. Perhaps it is worth considering what human questions the diagrams are supposed to be answering as a guide to how important they may or may not be. Again, maybe it is possible to make them more useful by making them less detailed and higher-level. For example, a flow diagram that shows a pseudocode principle of operation rather than all of the implementation details. Or perhaps two diagrams, to show both the pseudocode (pseudoflow?) and the implementation.
Sorry, this was a bit of a wall of text, which is slightly ironic considering that much of it is written in favour of summarisation.