You don't state the purpose. If you want to fully understand the format and not just automate certain initial aspects of the analysis, it will be very hard to come up with a generic enough tool. This is what domain-specific languages and extensible tools (010 Editor, scripting languages) exist for. I'm not aware of any tools that would "do it all" at the moment.
Tools such as 010 Editor in fact provide additional useful information such as a histogram (giving clues about the entropy, compression/encryption) and give you the binary templates to refine your knowledge about the file format more and more. The most annoying aspect is how limited the scripting is and that you can't, for example, write plugins (imagine being able to decompress bzip2 or deflate streams and such, something commonly found but not at all supported by 010 Editor). One of the major sore points with me and 010 Editor has been that I hit some syntactic limitations of binary templates to express something vital and had to work around that in weird ways (parametrized structs being a major pain), although this is exactly the problem it tries to address with its own DSL. I think we're in dire need of a FLOSS solution (and I was in fact looking into Luaizing frhed at some point).
A file format could be under a layer of encryption or compression and that could be separate per section of the file, not per file. There could be several layers. While I don't want to go as far as to state that it's outright impossible to come up with anything like that, there is a reason why IDA is interactive, for example. In most RCE tasks even the best heuristics can't replace the skills and experience of a seasoned reverse engineer. From experience I would apply the same to reverse engineering of file formats.
I, too, reversed some file formats and usually use a combination of writing a parser in a scripting languages on one hand and writing a binary template for 010 Editor on the other hand. The latter provides a nice fallback, because even if the parsing fails, I can go there, investigate what's going on, adjust and re-run. Lather, rinse, repeat ... you get the idea.
The biggest challenge by far was finding out the more arcane aspects such as integers encoded in 24 bit, sometimes LSB and sometimes MSB first, dates, trees based on xoring two indexes from elsewhere, a few bits being used from one byte and a few from another having particular meaning... that stuff. And I really cannot imagine how you would fill those gaps without reverse engineering the code reading/writing the format originally. Lacking any documentation/standard, it's the best reference you got.
Also, don't underestimate the power of visualization. Of course a single angle, such as a histogram, only provides little information. But there are plenty of interesting algorithms to apply to unknown data and see structures.
