One tipping point is when you find that Test Plans are more useful than mere Runs. Obviously this is impacted by the dev/test methodology used and how big the system under test is. An old school way of looking at Cases, Suites, Runs, and Plans is a sheet of paper, tab separated sheets you may wish to execute (or not), duplicated test results sheets or collection of sheets, wholly duplicated binders of test results.
When you find your testing questions focusing around “Do we need to execute these tests this time around?” or “Do we have tests that test ‘x’?” That’s the time to think about suites and plans rather than mere cases and runs. Obviously care must be taken to organize suites that make sense from the point of opting to test something in detail. If you are just doing Smoke and Acceptance… create separate suites for that. Reserve the fine grain of suites for detailed regression testing that perhaps you do only once a release. Or if you have the option, automate your regression suite testing and reporting.
Automation and types? To date I’ve not found a compelling reason to put automated test results in TestRail… usually the automation itself winds up reporting results independently of TestRail. I reserve TestRail for help in organizing those tests that don’t lend themselves readily to automation. Of course, if you find TestRail dashboard essential to making release decisions and need ALL testing results reported there, then you have a different problem to solve.