I don't know the semantics of PL_markstack_ptr, but I would guess that it's an internal detail that might be subject to change in the future.

It's documented in perlguts, though reading that documentation has not helped me any.
I think that makes it public - at least public enough that any alteration to its usage will be outlined in perlguts. And it has been in Inline::C and Inline::CPP for a very long time, without ever causing problems.

For me, it's more about removing arcane clutter that is deployed only by Inline::C/CPP, rather than looking for improved running performance.
Many of the "truly void" functions (eg those that don't invoke dXSARGS) don't even need to increment the ptr - so, for them:

void
foo (x)
    SV *    x
        PREINIT:
        I32* temp;
        PPCODE:
        temp = PL_markstack_ptr++;
        foo(x);
        if (PL_markstack_ptr != temp) {
          /* truly void, because dXSARGS not invoked */
          PL_markstack_ptr = temp;
          XSRETURN_EMPTY; /* return empty stack */
        }
        /* must have used dXSARGS; list context implied */
        return; /* assume stack size is correct */
[download]

can be rewritten as:

void
foo (x)
    SV *    x
        CODE:
        foo(x);
        XSRETURN_EMPTY;
[download]

which is much more readily comprehensible, and much more concise.

See https://github.com/Perl/perl5/issues/21523 where the issue was first reported. And also see https://github.com/ingydotnet/inline-c-pm/issues/104 for a bit of a discussion, and for Tony Cook's solution that suppresses the warnings shown in the former link.
I've actually started using a hacked Inline::C that eliminates the need for relying on "the PL_markstack_ptr dance". (It's based on the idea mentioned in that bug report - though it required some additional refining not mentioned there ... and it's probably not everyone's preferred approach.)

Cheers,
Rob