To pile on, you're right that editor-friendly formats aren't a great idea, but its not because how easy they are to edit, its because editor formats are built for editing and don't have any concern about hitting soft-real-time requirements, or how small they need to be to suit disk-bound or digital distribution.
The ideal formats for AAA and very demanding games are minimal processing between reading and seating them in memory -- data should, per-platform, be read into its exact in-memory format, complete with proper padding, alignment, and data-representation, when possible (zero-out the padding, for security and better compressibility). That allows data to be round-tripped with no intervention in theory, in practice, you'll probably want to do a minimal amount of validation.
For games that aren't as demanding, typically digitally-distributed ones (Indie games typically fall into this category, though not all that do are indie), file size and simplicity are often better goals to strive for. For that, you'll probably want a binary file format that's a sequential representation of the in-memory format, but which removes padding and ignores alignment. Then, you'll probably want to compress the entire packfile or whatever with something like zlib. For some file types, like textures, that have specific, effective compression like DXT and friend, you'll want to do that before compressing further, or maybe use a scheme that only compresses files without specific compression methods.