Per-file history is the timeline of a single file's versions, viewed independently of the project-wide commit graph.
On a code project this is a convenience; you usually think in terms of commits and pull requests. On an asset project it is the primary view, because the question people actually ask is about one thing. "What did this material look like before last Tuesday?" is a per-file question, and answering it by scrolling a commit log that also contains three hundred unrelated actor changes is miserable.
It also changes who can use version control at all. An artist who will never learn a commit graph can absolutely understand a list of versions of the file they are working on, with dates and authors, and a button to bring one back. That is the difference between source control being a tool the whole team uses and a tool the programmers use on the team's behalf.
In USourceControl every file has this view, and restoring from it creates a new commit rather than rewriting history, so the version you restored away from is still there if you change your mind.