As EWClay mentioned, it'd be better to pass it through to functions individually.
In SFML, in most situations, you might actually want to take a non-const sf::RenderTarget by reference, like this:
void MyGameObject::draw(sf::RenderTarget &renderTarget)
{
//...
}
Since sf::RenderWindow inherits from sf::RenderTarget, and since the function takes the sf::RenderTarget by reference, you can pass a sf::RenderWindow to the function and it'll still work like normal. But it also adds the additional benefit that you can pass other types of sf::RenderTargets (like off-screen buffers) to the functions as well.
Another benefit to passing things directly to functions, instead of making sf::RenderWindow static, is that not every function in different classes need to know about it, and it's good style to limit what code can access what.
Also, you might later decide to actually have more than one window (which SFML supports, iirc), and if you pass to functions instead of functions accessing it globally, you can use the same functions to draw to either window, just by passing the different windows as parameters.
A fourth reason to not make it static or global is that if it's static or global you might be tempted to use it in the constructor of some class or another, and then you might be tempted to make that class global as well. The problem is, the order of initialization of static/global variables is not defined, so it can lead to broken code that is confusing to debug - your class might be constructed first and try to use the RenderWindow that hasn't been created yet.
The only guarantee of global/static variables is that they'll all be initialized (in an unknown order) before you enter main() - but if they depend on each other, it may appear to work with one compiler and break with another.