To be confident that the application is working correctly there is no shortcut that should be taken. Every decision point needs to be tested at least once and as many combinations of those decisions as possible should also be exercised. Of course if you knew exactly how often each decision point is utilized, say, for instance, 1 in 10,000 times point AB is accessed, then you could put its test at the bottom of the priority list and maybe not have time to test it at all. That could be decided to be an acceptable risk by your company, otherwise it is the best decision to test all possible functions.
I agree w/Rich, along w/the flowchart you need some idea of the system under test. Certain paths will probably be more common than others, so focusing your tests where the majority of the users will be makes the most sense.
If you have access to a SME (Subject Matter Expert), designer, support person, etc. who can help w/that it would be useful to get their input.
Also, have you spoken w/developers? Are there paths that they are concerned about? Or that are left until late in the coding window since they are "less important" or "easy to do"? You may get a feel from them on areas that may be less stable than others, in which case, you may want to make sure you hit those sooner rather than later too.
I would like to add a few more points to what Rich and Klein said above.
1.Identify the end-to-end paths, and give them high prioroty.
2.Identify the paths that the users traverse most of the times and give those paths hight priority.
3.When truth tables are prepared, you can ignore the "don't cares".