In general, RTC is customizable. Like with every tool, there are limitations in what can be done and it is a good advice to stay within the limitations. Some limitations can be overcome if throwing enough custom coding and computational power at them, some can't. So it is a good idea to understand the limitations. Here material I presented last year about what I think the limits are: https://rsjazz.wordpress.com/2016/07/15/rtc-process-customization-what-you-can-and-cannot-do/

RTC does not support any custom data types similar to e.g. Clear Quest stateless records. So it is impossible to define and use such built in business objects and have effects like changing such a stateless record and have all work items/work item attributes referring to that record reflect the change. There is no mechanism in RTC to define a way to present multiple attributes of a complex referenced object in the work item or pull information from a referenced object into the work item for display on open. There is no real solution to implement anything like this in RTC, I would be aware of. From my perspective, this kind of behavior is one of the things you can not achieve in RTC.

It is possible to some extend to use RTC work items to store custom data and use either work item/work item list type attributes or links to store the relationship. Still, if the work item is changed, the change is not reflected in the source work item refering to that work item (except the summary displayed). There is also a host of other limitations e.g. there is no built in mechanism to define a query for work items to choose from in the attribute presentation/value picker.

I think it is important to note, that RTC was not intended to replace extremely customizable change management tools that support most complex custom business processes. The intent was to have a simple tool that supports agile development with some basic customization capabilities. This is what RTC is and it got pushed a little bit further over the years. However, I think RTC needs something like stateless records, if customer want so complex business logic and would welcome enhancement requests from customers. Using String type values via the HTTP filtered value sets does also not address the update issue. 

Using Reference Presentations to Create Links and Show Linked Work Items in RTC allows to refer to work items that are linked and to display them. The work items however are not updating linked work item values automatically. In fact the whole idea of OSLC is to avoid all these update dependencies and all the problems they entail. You can use follow up actions https://rsjazz.wordpress.com/2012/07/31/rtc-update-parent-duration-estimation-and-effort-participant/ to do automation, with the usual penalty. Note that link changes can not be detected for OSLC links. Only Work Item Link type changes can be detected in operational behavior. See https://jazz.net/wiki/bin/view/Deployment/MultipleCCMAppsUserPerspective for link types. You can only create custom link types for work item links.

Using real attributes to represent connections and manage back links etc is most likely the wrong decision. Attribute values are not meant as a two directional relationship. In addition attribute values are incapable of representing M:N relationships. Any attempts to use customization to keep attribute references stable are likely to be brittle and drain performance. I would stay away from such attempts.

As mentioned links have other limitations. Without really knowing what the use case and the underlying business case is, there is no way to provide a good answer.