In Scrum, from a process perspective, you generally have at most a 3 tiered hierarchy of parent/child relationships the most basic being a single tier.

Epic -> Story -> Task

Defect -> Task

Story -> Task

Story

Defect

With RTC, from a tool perspective, you can have hierarchies that are multiple levels deep and can consist of work items that are the same type in a parent/child relationship, so really any way you want to set up the parent/child link can be done from a purely technical level.

Story -> Story -> Task

Defect -> Task -> Task

Epic -> Epic -> Story

Those only being a few examples, the point being that RTC doesn't by default limit the types of work items that can exist in a parent/child relationship, the only constraints are;

Parents can have many children

Children can only have a single parent

It would not be unusual to see in Scrum a need to decompose a task work item into sub-tasks, however it is not typical to have a story as a child of another story, more commonly the story is a child of an epic where the epic is tracking all the stories that are being worked on in specific sprints but are just the larger epic broken down into smaller units of work/functionality being implemented.  There might be cases where a story needs to be linked to another story to describe a relationship (not necessarily parent/child) so a team can keep track of stories that impact one another for technical, business, or other reasons.

So, yes in RTC parent/child relationships can exist even when they are of the same work item type, the better question would be to ask why would you want to do that and what benefit does it provide the team.  A story to story parent/child relationship would probably just introduce confusion.

For defects requiring many hours to fix, add child tasks if there are multiple resources that are addressing the fixes in the defect.  Cross iteration (Sprint) work on the same defect might warrant the team looking to an epic that can sit cross iterations but tie all the child work (tasks) for the defect fix together.  I would recommend keeping stories to a level of planning where it will always be completed and closed at the end of an iteration.