Is it because this request to generate a challenge is coming in via a GET request?

Yeah -- the write guard is for the case where you load the form for the first time and it says "hey, answer this MFA challenge".

Sometimes that's in response to an actual form POST, but sometimes it's a GET or not a CSRF'd POST. One example is that when you GET into the "VCS Password" settings page, we immediately prompt you for MFA (admittedly, this is a little weird).

magic herbs that ward off evil CSRF spirits

A lot of the way it's hooked up is pretty magic, but the actual implementation is as dumb as rocks.

We tell the query layer "before you do any write, call this method" (in AphrontApplicationConfiguration):

$write_guard = new AphrontWriteGuard(array($request, 'validateCSRF'));

This object is magic and registers itself with the query layer. A more modern implementation would probably be a little less magic, but this was written in like 2011.

The query layer tests each query to see if it starts with "SELECT", "SHOW", or "EXPLAIN". If it doesn't, it determines that it's probably a write and calls the callback:

// NOTE: The opening "(" allows queries in the form of:
//
//   (SELECT ...) UNION (SELECT ...)
$is_write = !preg_match('/^[(]*(SELECT|SHOW|EXPLAIN)\s/', $raw_query);
if ($is_write) {
  // ....
  AphrontWriteGuard::willWrite();
}

The callback checks that $_REQUEST has a valid CSRF token. If it doesn't, it throws an exception.

Why are we calling save() instead of letting newResultFromIssuedChallenges implementations handle that (especially if those implementations might have their own special form of persistence)?

Mostly, just so that we don't have to have a lot of unguarded write boilerplate in every single implementation.

Challenge has a freeform $properties property, so my expectation is that any reasonable MFA factor implementation doesn't need other persistence. If that turns out to be untrue, maybe this was a bad call.

In theory, the write guard mechanism works with any service that does writes, although I'm not sure we ever bothered to implement it in any others. There's normally no way to do a service write without also doing a database write, and service writes are normally not interesting/dangerous (e.g., uploading data to S3 or whatever, I guess?).