-n forces the program to loop while there's still input from a.txt.

Yes but ...

I assume this also takes into account input from <STDIN> as well in the event b.txt is longer than a.txt, but I'm unclear on that point.

No. -n doesn't consider STDIN (thus b.txt) at all.

My assumption was that the two files are the same length as the OP made no mention of what should happen otherwise. But ...

If B is short than A, the last lines of A will be output with nothing from B.

If B is longer than A, the last lines of B will just be ignored (never read).

-l tells perl that a carriage return is the record separator, and chomps each line from a.txt, and sets the output record separator to the same, so each line printed should have a carriage return.

Yes, but I use printf rather than print which si not affected by the setting of the output record separator.

This may also chomp input from b.txt, but I'm unclear on that.

No. The record separator from b.txt is left in place when <STDIN> is read, so it provides the newlines for the output.

I don't understand why scalar is in place for the <STDIN> that is ingesting b.txt

Because printf provides a list context which would cause <STDIN> to slurp all of b.txt and append it to the first line of a.txt. By providing a scalar context it ensure that only one line is read from B for each line from A.

To those of us ... who don't often use the CLI, no, it's not quite as simple as it would seem to you.

I process lots of unstructured data; hence I use these facilities a lot and so I've become very familiar with this aspect of Perl. I guess it took your analysis of the one-liner to cause me to realise just how much implicit behaviour my "simple" one-liner made use of to do what it does.