(I did not make this up; I got it from here.)
The flag here is the family
$checked01,
$checked02, etc. Such code is almost always improved by
replacing the family with an array, and the repeated code with a
loop:

$checked[$_] = $FORM{"h$_"} for "01" .. "06";

Actually in this particular case a better solution was to eliminated
the checked variables entirely, but that is not what I
was planning to discuss. Rather, I planned to discuss a recent
instance in which I wrote some code with a family of variables myself,
and the fix was somewhat different.

The program I was working on was a digester for the qmail logs,
translating them into a semblance of human-readable format. (This is
not a criticism; log files need not be human-readable; they need to be
easy to translate, scan, and digest.) The program scans the log,
gathering information about each message and all the attempts to
deliver it to each of its recipient addresses. Each delivery can be
local or remote.

Normally the program prints information about each
message and all its deliveries. I was
adding options to the program to allow the user to specify that only
local deliveries or only remote deliveries were of interest.

As you see, this is where I made my mistake, and introduced a
(two-member) family of variables. The conventional fix says that this
should have been something like $do_only{local} and
$do_only{remote}. But I didn't notice my mistake right away.

Later on, when processing a message, I wanted to the program to scan
its deliveries, and skip all processing and display of the message unless
some of its deliveries were of the interesting type:

if ($local_only || $remote_only) {
...
}

I had vague misgivings at this point about the test, which seemed
redundant, but I pressed on anyway, and found myself in minor trouble.
Counting the number of local or remote deliveries was complicated:

There is a duplication of code here. Also, there is a waste of CPU
time, since the program never needs to have both numbers available.
This latter waste could be avoided at the expense of complicating the
code, by using something like $n_remote_deliveries = keys(%{$msg->{del}}) -
$n_local_deliveries, but that is not a good solution.

Also, the complete logic for skipping the report was excessively
complicated:

but that is not addressing the real problem, which was the family of
variables, $local_only and $remote_only, which
inevitably lead to duplicated code, as they did here.

Such variables are related by a convention in the programmer's mind,
and nowhere else. The language itself is as unaware of the
relationship as if the variables had been named
$number_of_nosehairs_on_typical_goat and
$fusion_point_of_platinum. A cardinal rule of programming is
to make such conventional relationships explicit, because then the
programming system can give you some assistance in dealing with them.
(Also because then they are apparent to the maintenance programmer,
who does not have to understand the convention.) Here, the program
was unable to associate $local_only with the string
"local" and $remote_only with "remote", and
I had to make up the lack by writing additional code.

For families of variables, the remedy is often to make the
relationship explicit by using an aggregate variable, such as an array
or a hash, something like this:

Here the relationship is explicit because $use_only{"remote"}
indicates an interest in remote deliveries and
$use_only{"local"} indicates an interest in local deliveries,
and the program can examine the key in the hash to determine what to
look for in the {lr} data.

But in this case the alternatives are disjoint, so the
%use_only hash will never contain more than one element. The
tipoff is the bizarre ($only_these) = keys ... line. Since
the hash is really storing a single scalar, it can be replaced with a
scalar variable:

A long time ago I started to suspect that flag variables themselves
are a generally bad practice, and are best avoided, and I think this
example is evidence in favor of that theory. I had a conversation
about this yesterday with Aristotle Pagaltzis, who is very thoughtful
about this sort of thing. One of our conclusions was that although
the flag variable can be useful to avoid computing the same boolean
value more than once, if it is worth having, it is because your
program uses it repeatedly, and so it is probably testing the
same boolean value more than once, and so it is likely that the
program logic would be simplified if one could merge the blocks that
would have been controlled by those multiple tests into one place,
thus keeping related code together, and eliminating the repeated
tests.