‘edit_theme_options’ capability seems to be self-explained. It’s primary purpose is to provide access to WordPress front-end theme options changing.
On practice, if you have ‘edit_theme_options’ capability, then you have access to the ‘Appearance’ menu at WordPress admin back-end and to its menu items: “Themes” (select a theme for your WordPress front-end) and “Menus” (edit menus supported by your selected theme). Customize theme header image, background color, etc. section and ‘Widgets’ menu items require ‘edit_theme_options’ capability also.

How it is realized? How often and at what places WordPress uses/checks this user capability – ‘edit_theme_options’ in order to decide give current user permission to edit theme options or prohibit access to such functionality? Let’s check this together. We will make a quick look into WordPress version 3.4.2 core source code and comment its related fragments.

This capability is self-explained and self-documented. It does that what it has in its name, really. If user has edit_plugins capability, he get access to the “Editor” menu item at the “Plugins” submenu of administrator back-end system menu. Of course, user should have “activate_plugins” capability too, as without such capability he could not access top level “Plugins” menu item. That is correct for single-site WordPress installation only.
For multi-site WordPress configuration:
1st, you should have super-admin privileges in order to be capable edit installed plugins files,

edit_files WordPress user capability introduced into WordPress since version 2.0 is not used anymore. It is added into current WordPress database schema for backward compatibility purpose with old themes and plugins, but no one line of WordPress core code uses this capability to take real decision about user’s permissions, allow or prohibit some operation.
Thus, I classified edit_files capability as deprecated and show it at User Role Editor plugin similar way as other deprecated capabilities like ‘level_1’, ‘level_2′, etc., that is hidden by default.
To see deprecated capabilities list at User Role Editor turn on “Show deprecated capabilities’ checkbox at the top of role editor form.

Suppose your site has a lot of user registrations and a lot of them are SPAM records. In that situation you could wish to delegate such spam users deletion to someone else. What capability is needed to get permission to delete unneeded WordPress users records? First of all, – delete_users capability. Is it enough? No. In order to delete user, you need to select it from user list. Thus, you should have some other user capability. Yes, it is 'list_users' capability. Without such capability you can not access your blog users list (“Users->All Users” menu item) under single-site WordPress installation and can not apply “Delete” command to selected user. Continue reading to see more detailed description and (if you curious enough) look inside WordPress core source code to know where and how WordPress implements ‘delete_users’ security permission.