First, thank you for taking the time to comment here. As an admin for the Theme Review Team, I am sensitive to end user needs, and ensuring that Themes hosted in the WordPress Theme Directory serve those needs to the greatest extent possible.
To address some of your issues as they relate specifically to Themes:
1. The Theme Directory listings are at a bit of a disadvantage as compared to the Plugin Directory listings. With the Plugin Directory listings, Plugin developers are required to include a README file that is compliant with a specific markup standard. The Plugin listing then parses that README file, to give the various headings/tabs that you see (FAQ, screenshots, etc.) in each Plugin's listing. The Theme Directory does not have this same README-parsing functionality, so Theme developers are limited to control over only the Theme description. Fixing this discrepancy is a (very) long-term goal/project of the small (for all practical purposes: one-man) team that maintains the WordPress.org site.
2. The Theme Review Guidelines require Themes to support core implementation of any integrated features/functions in a Theme. So, for example, if a Theme wants to implement a custom header image feature, or a custom background feature, or navigation menus, then the Theme must use the core implementation of those features, rather than create a redundant implementation of those features. So, for all core-implemented features, users should look first to the Codex for documentation of those features.
3. The Theme Review Guidelines do require Theme developers to provide documentation for any non-standard feature/functionality of the Theme. So, for example, if a Theme implements a "featured posts" slider, then the Theme must document how that slider works (e.g. using sticky posts, or using a "featured" category or tag, or a "featured" custom post meta key).
4. But, as mentioned above, there is no user-friendly display of a Theme's README file. Unfortunately, there's simply no way to parse/display them in the Theme's directory listing page.
5. If you find Themes that don't have non-standard features documented well enough, please post in the Theme's specific support forum.
6. But always, please keep in mind, the vast majority of people who submit Themes to be included in the Theme directory are submitting free code that they have developed on their own time. Writing user-friendly documentation is a skill; it is hard, and it is time-consuming.
7. While I do intend to push for Themes to have Plugin readme-standard compliant README files, it would be impractical to try to define some standard of inline documentation, and would incur an incredible burden for an already very busy Theme Review Team.
Here's my own Theme, Oenology. I consider its documentation to be a feature. I can't tell you how many hours I've spent on documentation alone, and it's still not perfect. I try to provide the same quality of documentation for my Plugins as well - but again, I don't think it's practical to try to require all Plugin and Theme developers to meet some level of quality of documentation.
Many Plugin/Theme developers are open to contributions to their code. The best places to start inquiries are the Plugin/Theme's specific support forum, or, as is often provided now, the developer's GitHub repository for the Plugin/Theme. Many developers use GitHub as a VCS, and welcome forks/pull requests. I imagine that the vast majority of developers who host their code on GitHub would practically beg for someone to help with their documentation especially.
If you have input or feedback regarding the Theme Review Guidelines, please feel free to contact the Theme Review Team directly. We always welcome any and all input, feedback, and criticism.