It's all dependent on your situation and who your is audience.
A couple of scenarios where this works:
Internet facing site. HTTP Zone, Anon. Access and HTTPS Zone to edit content. Restrict access to edit HTTP via web policies in Central Admin. With this approach you need to educate your content authors about watching for posting HTTPS links to HTTP users. Not only does this break the user experience it opens you up to a number security exploits.
Intranet / Extranet. One zone handles native authentication for your internal users, one zone handles authentication for your extra net users. If you are using separate authentication sources you will not need web policies to restrict access. The drawback with this approach is when you start sharing links across zones it can be confusing (i.e. internal user emails their link to external users). 2010 supports multiple authentication methods in a single zone as well, achieving similar result by separating users via authentication mechanisms.
Generally speaking, in MOSS you have a default zone on HTTP, and if you wanted to use HTTPS you extended the webapp. This was because of issues with Search. This works like the first scenario, and we lock down HTTP so only the crawl account has access.
As far as locking down SP Designer, this approach works in 2007, but you need to make some modifications to block SPD on the zones you don't want it used. In 2010 you can use the built in permissions sets to achieve this, so you don't need AAM and different zones to achieve this result.