In general:
A profiler is running all the time, so it gives you the complete call stack; at any given point in time.
A sampler only takes “snapshots” at distinct point in times.
Thing is: when you “profile” everything, then that slows down your JVM significantly; and it creates enormous amounts of data within a few seconds. Think about: the profiler will write down each and any method invocation that takes place!
So typically, you initially use a sampler, when you have “no idea” what is going on within your application. And then you just hope that the samples tell you something; like “hey, within our 10K samples, we are in that one method most of the time, why is that?” But as soon as you have a better understanding what you are “hunting” for, you would try to do a full profiler run in order to capture the whole call chain that leads into some method.
And then there is some “middle ground” – where you profile “everything” but exclude things. In other words: most profilers allow you to say “do not profile methods in classes in this or that package”. But of course – excluding packages/hierarchies only makes sense when you already have a pretty good feeling which direction you intend to investigate.