The hierarchy select only returns database fields. The purpose of non-db fields are for display only and will not be returned by a hierarchy select.

This does not seem to be true for address.full_address, which is setup the same way (but in baseline)

<hierarchy_select return_only_requested_attrs="true">
  <attrs>
    <attr>address.address_id</attr>
    <attr>address.full_address</attr>
  </attrs>
  <from>
    <table>address</table>
  </from>
  <where>
    <data_constraint>
      <constraint>
        <left_operand>address.address_id</left_operand>
        <operator>eq</operator>
        <right_operand>324</right_operand>
      </constraint>
    </data_constraint>
  </where>
</hierarchy_select>

gives the full address.

<address_hierarchy_select_result result_name="">
  <address>
    <address_id>324</address_id>
    <full_address>Streetname 123
Placename 2323 AB
NL</full_address>
  </address>
</address_hierarchy_select_result>

Also, regardless of the hierarchy_select, which was just a proof of principle, the custom request_contact.full_name is also not available in e.g. UI screens.

So what makes the baseline address.full_address different from our custom request_contact.full_name?

<hierarchy_select return_only_requested_attrs="true">
  <attrs>
    <attr>address.address_id</attr>
    <attr>address.full_address</attr>
  </attrs>
  <from>
    <table>address</table>
  </from>
  <where>
    <data_constraint>
      <constraint>
        <left_operand>address.address_id</left_operand>
        <operator>eq</operator>
        <right_operand>324</right_operand>
      </constraint>
    </data_constraint>
  </where>
</hierarchy_select>

<address_hierarchy_select_result result_name="">
  <address>
    <address_id>324</address_id>
    <full_address>Streetname 123
Placename 2323 AB
NL</full_address>
  </address>
</address_hierarchy_select_result>

The difference is that the concatenation is built into the baseline code. The full_address column is a special case as baseline code returns the concatenated field. By default only db fields are returned in a hierarchy select.  

A possible workaround would be to create a custom SQL view that would do the concatenation. Something like this perhaps:

CREATE VIEW request_contact_full_name_view AS
SELECT 
 request_contact.sequence
 ,CONCAT(request_contact.first_name, ' ', request_contact.last_name)
  as full_name
FROM request_contact

Then you would need to create custom metadata for the new view and the two columns, paste the view creation script into the Table Script field, and link the view on the UI Designer to the request_contact table using the Edit Child Relations window, joining on the sequence key. At that point, you should be able to paint the full_name field onto the screen.

A simpler alternative on the screen level would be to use the screen field “expression” property. First paint some unused request contact user def on the screen, then change the name of the field to one of your choosing, like request_contact.full_name. Tick the non-db box, and put an expression using the syntax similar to Business Rules:     

request_contact.first_name+" "+request_contact.last_name