How can UserA programmatically replace a text string within a file they own that's located in /etc?

Use ed rather than sed. This is normally an interactive editor, but you can feed commands to its standard input using a here-doc.

ed /etc/filename <<EOF
1,$s/old/new/g
w
EOF

This is not the safest way, as an error in the sed script will result in the truncation of /etc/targetfile.

To get around the inability to write temporary files to /etc, of course the naive way would be to try and sed [...] /etc/targetfile >/etc/targetfile, which would truncate /etc/targetfile before /etc/targetfile has had a chance to be read by sed; one way to get around this would be to use sponge, which won't overwrite the target file until STDIN has been fully read, effectively preventing the truncation of the source file before it has been fully processed, at the same time allowing to go around the limitation imposed by the permissions on /etc.

Per its man page:

sponge reads standard input and writes it out to the specified file. Unlike a shell redirect, sponge soaks up all its input before opening the output file. This allows constricting pipelines that read from and write to the same file.

sed [...] /etc/targetfile | sponge /etc/targetfile

I'd just use awk and store everything in memory then write it out at the end (after awk has closed the input file), e.g. using any awk:

awk '
    { sub("^f4442:/dir1/dir2/59.35:N", "f4442:/dir1/dir2/59.77:N"); rec=rec $0 ORS }
    END { printf "%s", rec > FILENAME }
' file

With the posted sample input note the change in the 3rd line from the top:

$ cat file
f1112:/dir1/dir2/59.35:N            # Comment
f3332:/dir1/dir2/59.35:N            # Comment
f4442:/dir1/dir2/59.35:N            # Comment
f555:/dir1/dir2/59.35:N             # Comment
f666s2:/dir1/dir2/59.35:N           # Comment
f777s2:/dir1/dir2/59.35:N           # Comment

$ awk '
    { sub("^f4442:/dir1/dir2/59.35:N", "f4442:/dir1/dir2/59.77:N"); rec=rec $0 ORS }
    END { printf "%s", rec > FILENAME }
' file

$ cat file
f1112:/dir1/dir2/59.35:N            # Comment
f3332:/dir1/dir2/59.35:N            # Comment
f4442:/dir1/dir2/59.77:N            # Comment
f555:/dir1/dir2/59.35:N             # Comment
f666s2:/dir1/dir2/59.35:N           # Comment
f777s2:/dir1/dir2/59.35:N           # Comment

If the file is large, though, I'd suggest using a temp file as:

tmp=$(mktemp) &&
awk '{sub("^f4442:/dir1/dir2/59.35:N", "f4442:/dir1/dir2/59.77:N")} 1' file > "$tmp" &&
cat "$tmp" > file
rm -f "$tmp"

In that way you're again only changing the contents of file, not replacing it.

P.S. Personally, I wouldn't use a regexp search and replace for this as it introduces too many gotchas regarding what could be present in the input and/or search string, I'd use literal strings instead, e.g.:

awk -v old='f4442:/dir1/dir2/59.35:N' -v new='f4442:/dir1/dir2/59.77:N' '
    index($0,old) == 1 { $0 = new substr($0,length(old)+1) }
    { rec = rec $0 ORS }
    END { printf "%s", rec > FILENAME }
' file

That would still have to be tweaked if the directory path could contain backslashes but that's easy to handle if necessary, e.g. see ENVIRON[] at how-do-i-use-shell-variables-in-an-awk-script.

I did not mention this case in the Perl Cookbook because it is so rare, but because your replacement string is the same length exactly as your original string, it actually is possible to update the disk file in place — simply by resetting your seek pointer back to where it had been when that line had been read.

The following code works on your file, as tested on an Ubuntu system:

#!/usr/bin/env perl

use strict;
use warnings;

###my $filename   = "$ENV{HOME}/tmp/targetfile"; # for testing
my $filename   = "/etc/targetfile";
my $old_string = "f4442:/dir1/dir2/59.35:N";
my $new_string = "f4442:/dir1/dir2/59.77:N";

length($old_string) == length($new_string)
    || die "old and new string must be the same length";

open(my $fh, "+<", $filename) || die "can't open $filename for update: $!";
$fh->autoflush(1);

my $filepos = 0;

while (<$fh>) {
    next unless s/\Q$old_string\E/$new_string/g;
    warn "updating line of $filename at position $filepos"; # or comment out if you're confident :)
    seek($fh, $filepos, 0) || die "can't seek to pos $filepos in $filename: $!";
    print($fh $_)          || die "can't write new line to $filename as pos $filepos: $!";
}
continue {
    $filepos = tell($fh);
}

close($fh) || die "can't close $filename: $!";

The moral of the story is that, rather surprisingly, you really can use the same handle for both reading and writing, if you're very, very, very careful—and only if there is a seek on the stdio filehandle between changing I/O "directions" (going from read to write or vice versa), as there is here. That's needed to keep the stdio buffer in order, and while perl uses its own I/O buffering system, the same inherited POSIX rules apply.

This approach is especially appealing because it no longer takes memory proportionate to the size of the file the way the nasty "read it all into memory first" approach does. That means you can run this on a file with a hundred million lines if you care to and it will consume no more memory than it would for a tiny file.

It’s awfully courageous, though, given the lack of backup.