First off, in retrospect, the use of static was probably a mistake. Not in the fact it's usage was wrong, but perhaps it was the wrong time to broach such a subject. A lot of that tutorial is actually geared towards illustrating various language concepts, over actually showing you how to use SFML. This means on occassion things are implemented a certain way because it became a convenient way to introduce a concept.
As to static itself, in the case it was used it was perfectly fine, but there is some need to understand exactly what static does. One of the big confusions is that static==singleton, which isn't specifically true, although the inverse is. Singletons are generally static.
When a variable is static, you are essentially taking it's allocation out of the traditional life cycle. When something is declared as static, it is created at the point the program is initialized. ( If you are wondering what happens when you have two statics... which is allocated first... this is a very good question! ). The major advantage of this is it means there can be only one. In cases where "there can be only one", well... this is obviously a very good attribute to have! The static in question was the game class itself, something that you cannot have more than one allocated. Of course, there are other ways to prevent this ( none quite as easily though ), as well, it is also a perfectly acceptable thing to not deal with and allow the code to explode if the user does try to allocate another.
Be careful with following rote advice, it can lead you into trouble. Far too often people like to pass off opinion as fact, especially in this field, and that is extremely dangerous. One classic example, there are a class of developers that subscribe to the single responsibility principle to a zealous degree. Many of these people will pass this off as a fact, but it isn't. It's one way of doing things, and in many ways a good way, but it is not the only way. Singletons are another great example with even more people willing to use absolutes like "never use a singleton", and I really don't want to rehash that old chestnut in this thread; but.... take a look out in nature and you will see it's pretty damned common in some really successful projects. Ogre, cocos2D, PlayStation Mobile SDK, Source Engine....
Oh, and starting with 1.6 and porting to 2.0 later is perfectly acceptable. Truth is, it's pretty easy too, and by part 7 or so I started providing 1.6 and 2.0 versions of the projects, thanks to a readers contributions. Both have their merits... 1.6 is the best documented version out there, but there is a nasty ATI related bug that the developer never bothered fixing. 2.0 is a bit cleaner, but is currently lacking in documentation and is technically a release candidate.
In the end the biggest code difference is the move to camelCase naming conventions and removal of GetInput from the window object, which from a design perspective, makes a ton of sense. With the way the tutorial was written though, this transition is pretty easy as I put a very small abstraction layer of the IO anyways. Perfectly demonstrating why it is you do such things.
