As you see from rjcup3's and PirateEric's answers, there are two kind worlds: ones who prefer SPD and ones who prefer VS.
I preferred VS for 5 years until I had to learn SPD. I'm happy it happened, as I learned the difference between the two.
Use browser until there comes a requirement you cannot fulfill using browser. Then see if it can be done using SPD. Only after that consider using Visual Studio.
If you have only one environment (=production) and you don't need to have strict version control of each feature and whatnot you create into SharePoint, feel free to use SPD. It's quick and easy. In this scenario VS might bring too much overhead compared to benefits.
If you have multiple environments (dev, test, production, etc.) and you need to have some sort of application lifecycle management in place, you will quickly learn to appreciate VS and SharePoint solutions (WSPs). If you would use SPD in this scenario, you'd have to document all changes you make and redo them manually in every environment. Using WSPs, you have version controlled code (possibility to have it at least), and you can deploy changes in coherent manner across environments. All this works beautifully on MSDN documentation, but in practice...well.
Do note that using VS will usually require more time and more effort when developing compared to using SPD. It's because VS is more powerful and learning curve is steep. VS is for enterprise class application development, and that control and all enterprise application development requirements come at a cost.
But you can also mix the two: use SPD to create most of the site, then perhaps create custom features/web parts/web templates using VS. For small scenarios with some custom requirements, this is the way I've preferred.