With a query like this it's possible Oracle will default to a whole lot of hash joins and full table scans, which may or may not be a good idea.
+1 to post the explain plan. Until then, don't upvote this answer!
I believe your query is equivalent to this, and it's possible that when you look at the explain plan that you'll see Oracle will convert it to something like this anyway:
select r.id
,uc.contributor_full_name,s.code
,d.text
,ucs.moderation_status
,v.url
from review r
join user_contribution_status ucs on r.user_contribution_id = ucs.user_contribution_id
join user_contribution uc on uc.id = ucs.user_contribution_id
join system s on uc.system_id = s.id
join accommodation_video av on r.accommodation_id = av.accommodation_id
join video_description vd on v.id = vd.video_id
join description d on vd.description_id = d.id
join video v on av.video_id = v.id
union all
select r.id
,uc.contributor_full_name,s.code
,d.text
,ucs.moderation_status
,v.url
from review r
join user_contribution_status ucs on r.user_contribution_id = ucs.user_contribution_id
join user_contribution uc on uc.id = ucs.user_contribution_id
join system s on uc.system_id = s.id
join location_video lv on r.location_id = lv.location_id
join video_description vd on v.id = vd.video_id
join description d on vd.description_id = d.id
join video v on lv.video_id = v.id;
Warning: I may have made some assumptions about constraints (e.g. PK, FK and not null) on some of the ID columns, esp. with regards to accommodation_video and location_video. I removed them from the subclauses with the assumption that they weren't necessary - but this assumption may be wrong.