Sub-tasks are an ordinary datastore, so they browse, filter, report and audit like anything else. A few conventions make them considerably more useful.
Reporting on progress
Counting open sub-tasks against a record is the usual way to show progress, and to stop a record being closed while work remains outstanding. Because sub-tasks work the same way for every datastore, one Browse View or Custom Query View covers all of them.
Set the completed date, not just the status
A status of "Done" tells you the state; the completed date tells you when. Any reporting on how long things take needs the date. Enforce it with a table rule that sets the completed date when the status moves to a completed value, rather than relying on people to fill it in.
Sub-tasks created by workflows
The Workflow Builder's Approval node creates a sub-task as its approval request. Note the limitation covered under Workflow Builder: completing that sub-task does not resume the waiting workflow, so you will find paused runs alongside completed approval sub-tasks.
Deciding whether the parent depends on them
If a record should not be closable while sub-tasks are open, enforce that in one place — a table rule or a workflow — rather than in each screen that closes a record. Otherwise the rule holds in some places and not others, which is worse than not having it.
Sub-tasks and the timeline
Use sub-tasks for work and the Activity Stream for narrative. The thing that needs doing is a sub-task; the note explaining why it was delayed belongs on the timeline.