SFML resources still "take care of themselves". Any SFML resource requiring an OpenGL context to be active will activate some implementation defined context and deactivate it once the operation is done. RenderTargets on the other hand need a bit more manual work to be done when multi-threading. Because SFML can't assume which thread is currently drawing to a RenderTarget the user will have to explicitly make sure it is deactivated on all other threads before activating it in a specific thread. Only the user can know when it is safe to do so so this is something SFML can't automatically do.
When it comes to raw OpenGL, the situation has changed from before the context changes. Where one could assume that SFML would leave a residual context active after any operation, one can't assume this is the case now. The "a context is always active" invariant was never formally defined anywhere before anyway and users just figured that part out on their own. This is the reason why some were surprised when this undocumented behaviour was changed.