The short answer is that you should use a Trigger when you cannot do what you want to do with the declarative features of Salesforce. Salesforce best practice states that one should leverage the declarative features of Salesforce first (#8).
Process Builder is improving with almost every release, and can be used with more and more complicated use cases. This link provides very helpful scenarios where Process Builder would be preferable to Triggers.
That isn't to say that Process Builder is a 'silver bullet' - there are still considerations to take into account. As per this link, I think the most compelling consideration is that from @cropredy:
If you use triggers, you are forced to write testmethods and if you do
a good job of this (lots of asserts, positive and negative tests,
...), you'll end up with a comprehensive set of regression tests
If you use Process Builder, this testing requirement has to be met in
other ways:
- A browser automated testing tool (Selenium)
- Your own (possibly haphazard) UI testing before release
- Wait for users to complain something isn't working
- Apex testmethods that simulate the CRUD event and then assert
expected results
Slightly unrelated to your question but quite interesting is that the gap in time investment between Flow and relatively simple Apex triggers isn't that much, so as per the Apex Academy video tutorial series on Pluralsight, it may be more beneficial and less 'technical debt' to use triggers in that particular use case.