creating an lvalue for it and assigning to that lvalue is a far more involved than C's simple process of doing some pointer math

Agreed. In part, that's why I hoped (forelornly it seems) that Perl 6 would allow the syntax $string[n] as an lvalue or rvalue to mean the same as substr($string, n, 1) once that syntax no longer conflicts with the @arrayn syntax.

From my best guess, and I realise that it is only a guess, the compiler should have enough information at compile-time to convert $string[n] =  'c' or even $string[n..m] into a direct read-from or write-to the scalar's storage without the need to generate a perl lvalue structure unless a reference is being taken.

Avoiding both the call overhead of substr and the need for generating the whole lvalue and associated paraphanalia, unless it is necessary, would allow bytewise manipulation of strings with significantly less overhead than is currently the case.

It is possible that this lack of direct access at the byte level of strings that allows perl to accomodate changes like unicode with almost no changes to the visible api's which is nice.

Perl is not C. The most efficient way of doing things in Perl is almost always to let the perl interpreter do as much of the job as possible, rather than spelling it out.

Perl's high-level constructs do obviate the need to do many things at the byte-wise level, but will never obviate them all.