Shorewall and Ferm are in my opinion the only two serious iptables frontends out there that you can trust on your servers. And yes, you want a frontend, because they make life easier, are more manageable, produce more readable configs and most important allow you to focus on your firewall design rather than the implementation. And with regard to that it's more likely that someone who has spent many years working with itpables knows better than you how to implement it. Besides if you have anything more complex than deny-everything-in/allow-everything-out, you will end up with some sort of framework to make things more manageable, in short build another, probably less featured, frontend. Obviously there are cases where you know what you're doing and you might need/benefit from direct iptables usage, but they are, or should be reduced to, very few. One of this is dynamic addition or removal of rules at runtime, or so I thought.

The problem in theory

Generally when you change something and issue a reload through the frontend all chains are flushed and rules re-added from scratch. Admittedly this sounds scary, especially on a busy firewall, and even unnecessary if all you want is allowing a new incoming port and a single rule in the right place would do.
Unfortunately there is no clean way to handle this. Quoting Thomas M. Eastep, shorewall's creator, as I couldn't better put it:

For more than 20 years, I've been involved in development projects
where there was a "real environment" (Netfilter in this case) and a
"shadow environment" (The firewall configuration tool). I've come to
believe that it is not possible for the shadow environment to have an
accurate idea of what the "real" environment looks like. So any
implementation where the shadow environment tries to make incremental
changes to the real environment will be broken in some cases. When
you are dealing with security, a system that is broken in *any* cases
is not acceptable. That is why Shorewall always rebuilds the entire
Netfilter configuration -- that is the only way that Shorewall can
guarantee that Netfilter is correctly configured.

In practice

In practice the problem is negligible because frontends tend to use iptables-restore to reload the rules (for shorewall you need the new shorewall-perl), which makes it very fast, down to few milliseconds depending on the size of your ruleset. Quoting from the frozen-tux itpables tutorial:

The main problem with running a shell script that contains iptables
rules is that each invocation of iptables within the script will first
extract the whole rule-set from the Netfilter kernel space, and after
this, it will insert or append rules, or do whatever change to the
rule-set that is needed by this specific command. Finally, it will
insert the new rule-set from its own memory into kernel space. Using a
shell script, this is done for each and every rule that we want to
insert, and for each time we do this, it takes more time to extract
and insert the rule-set.

To solve this problem, there is the iptables-save and restore
commands. The iptables-save command is used to save the rule-set into
a specially formatted text-file, and the iptables-restore command is
used to load this text-file into kernel again. The best parts of these
commands is that they will load and save the rule-set in one single
request. iptables-save will grab the whole rule-set from kernel and
save it to a file in one single movement. iptables-restore will upload
that specific rule-set to kernel in a single movement for each table.
In other words, instead of dropping the rule-set out of kernel some
30,000 times, for really large rule-sets, and then upload it to kernel
again that many times, we can now save the whole thing into a file in
one movement and then upload the whole thing in as little as three
movements depending on how many tables you use.

As the author points out there are drawbacks to iptables-(save|restore), you can read more about it here

Shorewall and Ferm do it differently

If you imagine iptables as a building's basement, Ferm is the first floor and Shorewall the second. This has absolutely nothing to do with their quality, just with their level of abstraction. Shorewall's grammar and semantic is built around concepts of zones, policies and other macro areas, whether Ferm uses a syntax closer to iptables commands (from the Ferm's manual: The structure of a proper firewall file looks like simplified C-code). As usual abstraction comes to a cost, in this case you lose some flexibility. In fact with Ferm, if you organize your configs such as different chains use different files (it's actually a bit more complicated than that but you get the idea), you can re-execute each of them on their own, thus limiting a theoretical service disruption.

Conclusions

With all that said, I'm happy with those few milliseconds it takes to reload my ruleset, especially given that none of this impacts on established connections and that TCP, which is most of my traffic anyway, can cope with a few lost packets. Although, even this might not be acceptable in some cases, and there are alternatives, including manual intervene, just keep in mind that such flexibility is far from coming for free.