Emily,

Applause for another well-written introduction to the concept.

Three quibbles related to emphasis:

1. The most important issue with late constraints in MSP is that the tool automatically defaults to "Tasks will always honor their constraint dates." This is a trap waiting to snare all newcomers with experience in other tools (like P3/P6).  Your write-up suggests that the decision to turn the option off depends on the project manager's assessment of whether out-of-sequence progress can be PLANNED FOR on a case-by-case basis in the schedule. Leaving the option checked effectively turns ALL late constraints (not case-by-case) into one-sided mandatory constraints - a type that doesn't exist in P6 and (in my view) doesn't belong in a logic-driven schedule.  Turn it off.
2. An extra reason to avoid any late constraints in MSP is that they may eventually come into conflict with the updating process that, in the absence of a true data date, sometimes requires the use of the single constraint available.  Deadlines are more suitable. 
3. It seems you really had to dig to the bottom of the barrel in searching for a feasible use-case for the SNLT constraint.  The example given - constraining an asphalt paving task to start before a particular date to avoid winter conditions - would ordinarily be much better addressed using a dedicated weather calendar for the task.  (I don't fault you for the selection; I can't think of a reasonable example for SNLT off the top of my head.)