I see objects as tool to organize data and related functions, and not much more. I don't really subscribe to the "greater theory of objects" that languages like Java force on people; maybe that's what you're referring to. I think pretty much any code is going to run into a pattern that could be helped along by some structure, though.

Your code provides a good example, actually. You seem to have a form that allows up to 5 instances of 9 search parameters (plus a yes/no 10th parameter for each instance after the first), multiplying out to 49 variables. You then end up repeating a lot of your code, once for each set of 9 parameters.

Consider if you group those into hashrefs, for each set of search parameters:

$searches,
# An arrayref of hashrefs like:
# {
#    searchver    => # BIBLE VERSION, I.E. TABLE IN DB
#    comp         => # COMPARISON QUERY TO MATCH AGAINST THIS VERSION
#    case         => # WHETHER TO MATCH THIS QUERY CASE-SENSITIVELY (B
+OOLEAN)
#    wholeword    => # WHETHER TO REQUIRE QUERY TO MATCH ONLY WHOLE WO
+RDS (BOOLEAN)
#    startverse   => # MUST MATCH AT START OF VERSE (BOOLEAN)
#    endverse     => # MUST MATCH AT END OF VERSE (BOOLEAN)
#    flexdelimit  => # MATCH WORDS DELIMITED BY USER-SELECTED DELIMIT 
+CHARS (BOOLEAN)
#    delimitchars => # ACTUAL CHARS TO USE AS DELIMITERS, AS ENTERED B
+Y USER
#    regex        => # USE PERL REGULAR EXPRESSION (BOOLEAN): VOIDS OT
+HER OPTIONS ABOVE
#    yn           => # WHETHER TO MATCH (YES) OR NOT (NO) (BOOLEAN)
# }
[download]

Now, the caller has to do a little more work to build that array of hashrefs to call this function. But, you were probably handling form-submission parameters by name anyway, so you can probably build them in a loop. The savings come when you start to use those:

( $ch, $noreplace )= resetBadBooleans( $ch, $noreplace );
for my $search (@$searches) {
  for (qw( case wholeword startverse endverse flexdelimit regex yn )) 
+{
    $search->{$_}= resetBadBooleans($search->{$_});
  }
}
[download]

The code here only got moderately shorter in number of keystrokes, but to my eyes it got a lot less error-prone, and easier to maintain. (and being perl, of course you have the option to code-golf this down to fewer characters...)

my @bool_keys= qw( case wholeword startverse endverse flexdelimit rege
+x yn );
@{$_}{@bool_keys}= resetBadBooleans(@{$_}{@bool_keys})
  for @$searches;
[download]

but use whichever one you think reads easier for you or a future maintainer.

Your function composeRegex uses 8 of these 10 hashref keys. Instead of spelling out all 8 arguments to the function like

$regex= composeRegex($search->{case}, $search->{wholeword}, $search->{
+startverse}, $search->{endverse}, $search->{flexdelimit}, $search->{d
+elimitchars}, $search->{regex}, $search->{comp})
[download]

You could just pass the whole "search" hashref to the composeRegex function:

$regex= composeRegex($search);

...

sub composeRegex {
  my ($search, $extra)= @_;

  # you might still un-pack these into local variables for convenience
  my ($regcase, $wholeword, $startverse, $endverse, $checkdelimit, $de
+limitchars, $useperl, $query)
      = @{$search}{qw( case wholeword startverse endverse flexdelimit 
+delimitchars regex comp )};
  ...
}
[download]

And, just like that, "composeRegex" has become a function that operates on "search parameter hashrefs" which is basically a few tiny steps away from being a method that operates on "search parameter objects". I didn't actually use any of perl's object-oriented features, yet, either. But that's the concept. You have a group of data (the "search parameters") and you have functions that need some or all of the search parameters, and those functions would become the methods of your search parameter object.