I was hoping to be able to require the dependent options within the getopt module

This is how I handle option dependecies. Whether it's clearer than your method is largely a matter of taste. You keep a dependecy near the code that mandates it. I group all of them near the GetOptions call.

use Getopt::Long;
use Pod::Usage;

my %opt;

GetOptions(
           \%opt,
           'help',
           'man',
           'V|version',
           't|timeout=i',
           'H|hostname=s',
           'p|port=i',
           'U|uri=s',
          ) or pod2usage(2);

# standard opt handling;
$opt{h}   && pod2usage(1);
$opt{man} && pod2usage( -exitstatus => 0, -verbose => 2 );
$opt{V}   && version();

# option dependencies
( defined($opt{U}) xor defined($opt{H}) ) || pod2usage(1);
defined($opt{H}) && defined($opt{p})      || pod2usage(1);


# ... go on your merry way knowing dependencies are satisfied

__END__

=head1 NAME

    opttest - Check out Getopt::Long and Pod::Usage

=head1 SYNOPSIS

    opttest [options] -U uri
      - or -
    opttest [options] -H <hostname> -p <port>

     Options:
       U | -uri         uri to check
       
       H | -hostname    hostname to check
       p | -port        tcp port to check (required with hostname!)
       ...

=head1 DESCRIPTION

    Optest provides some basic option handling and demonstrates
    how to handle option dependencies for most-likely cases.

=cut
[download]

Adding some feedback to the user also helps the code self-document, but does create some clutter:

( defined($opt{U}) xor defined($opt{H}) )
  || do { print "Only one of 'hostname' or 'uri' must be specified\n";
          pod2usage(1);
        };
defined($opt{H}) && defined($opt{p})
  || do { print "Hostname option requires port option\n";
          pod2usage(1);
        };
[download]