Render Array Options

They are mostly arbitrary, which is why you aren't finding anything.
You can always use #markup, #prefix and #suffix,

Let's say I create a page. This page returns the name of a single user, themed accordingly. First, let's look at the situation where I want to return a message saying that no friends are found. I can use #markup, #prefix and #suffix:

return array
(
  'no_users_found' => array // They key is chosen by me. Something descriptive.
  (
    '#markup' => t('Sorry, no users were found'),
    '#prefix' => '<p>',
    '#suffix' => '</p>'.
  ),
);

I am returning a render array, and assigning it an arbitrary key ('no_users_found'). This key allows someone looking at the render array further down the line, say in hook_page_alter(), to know what they are looking at. By setting the message as the #markup, with the wrapping tags as #prefix and #suffix, the themer can come along and use different tags if they want, say H2 tags instead. Or they can change the message. They can even redefine or remove the entire section of this array if they want.

If you use the #theme attribute, you will also have to pass any values that the theme() function would expect. Let's look at theming usernames. If we were to use the theme() function to render a username, we would need to pass it a fully loaded $user object, like this:

$themed_username = theme('username', array('account' => $account));

We could even return that username using #markup:

return array
(
  'user_found' => array // They key is chosen by me. Something descriptive.
  (
    '#markup' => theme('username', array('account' => $account)),
    '#prefix' => '<p>',
    '#suffix' => '</p>'.
  ),
);

This will work, but the username is rendered right away, and there is no opportunity to change it. Or maybe somewhere else down the line, someone needs the User ID, but since it's been rendered, it's not available. In this case, we can instead use the #theme element, and pass the $account object, as #account:

return array
(
  'user_found' => array // They key is chosen by me. Something descriptive.
  (
    '#theme'  => 'username',
    '#account' => $account,
    '#prefix' => '<p>',
    '#suffix' => '</p>'.
  ),
);

In this above, I am passing the #theme (username), with the required elements for the theme (account), but adding a # to the start of the required elements (#account). If you go to the theme_username() page, you can see that there are other values that can also be passed: #name, #extra, #link_path etc. You can add any of these as necessary. By returning this value, the username is not rendered until the array is passed through render(), meaning that themers can alter it and/or use the data in the $account object, right up until the last possible moment before rendering (which should be the last thing done).

As you can see, the #attributes are determined by the expectations of the theme_function/template that will be used to render the array. Since any theme function can determine its own requirements, this means that the #attributes of a render array are up to the theme, and are entirely arbitrary, which is why you are not finding a list of them.

Finally, there is the #type attribute. When creating forms, the #type element can be used (along with the #theme element if one were to want), and this will require the user to include certain attributes (for example, checkboxes and radios will require the #options element). These also come with their own built-in default theming, which you can ignore. This theming can be overridden (for example, override theme_checkboxes(), but I will not be explaining that here.

Hopefully this gives you a better understanding of what is going on when you return a render array from a function.

I understand the original post and your reply both link to the api page for render arrays... however my point (and that of the OP) is that render arrays are very poorly documented. The page you link to says

Looking through system_element_info() we see a pile of predefined #types, including page, form, html_tag, value, markup, link, fieldset and many more.

(buried far down in the text). My point is that the form api reference is a very clean and fast means of displaying all the options available to the form api, and that render arrays could use a similar page. It seems like having to dig through multiple pages of api references instead of having clear and concise documentation discourages the use of what is a very powerful system.

You can also use #theme_wrappers to define a theme function to wrap around the element in question.. which is far better than using #prefix or #suffix, since those are straight up strings, whereas #theme_wrappers could define a template file or a theme function - which once in place could be overridden easily in the future. But #prefix and #suffix will get the job done if you only need to set one or two elements that way. I have no idea why the api reference page says its 'rare to use it with #theme' - thats just unwarranted opinion injection - imo.