Well, it would be consistent with the rest of the API. I think that it might be the only setter without a getter now, except for getIcon (#513) which has a technical reason for not existing, and maybe SpriteBatch:get if that counts (I'm not suggesting this should exist, I haven't really thought about it). It also makes the API less complex, because otherwise you have to be aware that setStencil doesn't have a corresponding getter, unlike almost everything else.
For a practical application, it could be used to remember the currently active stencil, set the stencil to something else, and then revert to the previous stencil.
One thing to note though is that it wouldn't suffice to simply return the function, it would also have to return whether it is inverted or not. So something like...
This is symmetrical with something I proposed for setStencil, which I didn't think of at the time.
(inverted could be a boolean or a string.)
I like this because it saves a function, saves the argumentless calls of love.graphics.setStencil() and love.graphics.setInvertedStencil() from being duplicates, and it's basically setting a variation of the same thing, so it just seems to make sense to me. The ability to have a symmetrical getter function seems like another reason why it makes sense.
So uh, when I'm like "hey, there should be a getter/setter for this thing", I'm completely unaware whether it's trivial or not-so-trivial to implement. I'm now assuming this is a not-so-trivial case, because I guess the function isn't really stored, right? Hence why setMode clears the active stencil? So yeah, basically, just wanted to remind everyone that I never have any idea about what I'm talking about, aaand therefore this issue should probably be ignored, heh. :)
The way stencilling works currently: when setStencil is called, the stencil buffer is activated and the function passed as an argument is called. The stencil function draws to the stencil buffer instead of the normal color buffer, and then the stencil buffer is deactivated for drawing (but still tested against until setStencil is called with no arguments.)
This means the function passed to setStencil is only relevant during the setStencil function call. The function draws to the stencil buffer. The stencil buffer is cleared when the OpenGL context is recreated (i.e. when setMode is called.) It's not practical to save it during the context recreation.
Each canvas has its own separate stencil buffer, which is why setStencil(func); setCanvas(canvas) doesn't work as one might expect. It's not technically feasible to make it work as one might initially expect (a global shared stencil buffer), either.
All this added up means that a getStencil just doesn't make sense, because the returned function wouldn't represent the actual state.