To be granted access to these ports, the installer must first turn off the personal firewall. Currently, it is not automatically re-activating the firewall once it sets up Version Cue CS3 Server, creating a potential security vulnerability.

This is a lie. There is no need to turn off the firewall to add rules. I just discovered that Apple's System Preferences appears to flip the firewall off and on to pick up new rules. This makes things simpler, as Apple can just use existing code to a) edit the configuration file, b) turn the firewall off, and c) turn the firewall on, rather than doing "live insertion" of rules. The truth is, though, that there are two different ways to add rules such as Adobe requires. Both are described in Apple's ipfw manual page.

Adobe's Details tells you what they require:

On Mac OS X, customers can turn on a personal firewall to control how Internet services communicate with their systems. During the installation of Adobe Creative Suite 3, the installer sets TCP ports 3703, 3704, 50900, and 50901, in accordance with Apple’s specification, to allow controlled access to Adobe Version Cue CS3 Server through the Mac OS X firewall service.

One way is to simply add rules individually, such as:

ipfw add 8001 allow tcp from any to any dst-port 3703 in
ipfw add 8002 allow tcp from any to any dst-port 3704 in
ipfw add 8003 allow tcp from any to any dst-port 50900 in
ipfw add 8004 allow tcp from any to any dst-port 50901 in

This is tricky, since Adobe doesn't know what rules their users have, and it's important to insert them into the right place in the sequence.

Another way is to update the rules file and then reload it, as described in the manual page:

To ease configuration, rules can be put into a file which is processed
using ipfw as shown in the last synopsis line. An absolute pathname must
be used. The file will be read line by line and applied as arguments to
the ipfw utility.

In Tiger, Apple's dispensed with the BSD-style rules file, and replaced it with an XML document. I don't know how Apple manages the XML configuration, and perhaps they don't provide a hook to update the live ruleset. Apple's tools should be doing this, but don't. At a guess, someone at Adobe decided to follow Apple's (bad) example and stop & start the firewall, rather than updating the XML configuration file (as they already do), figuring out where the new rules would show up, and then live inserting them (see "ipfw add", above).

Stopping the firewall temporarily is opening customers to unnecessary risk. It's bad, but Adobe's in good company here. On the other hand, saying this is necessary is either a lie about security (never a good idea) or gross technical incompetence (not a real improvement).

If they didn't have the unfortunate bug, whereby the installer neglects to restart the firewall after it's disabled it, we might never have noticed.