The reason that calling TileHandler in a static context is not the best possible design, is that it couples components of your design that could otherwise be decoupled.
If you choose to have more than one TileHandler in the future, you'll have to do a lot of work to accommodate this change.
If you choose to remove TileHandler, you'll have to do a lot of work to accommodate this change.
Suppose you build a different level/zone in the future, that handles tiles in a different way from your current TileHandler. Then you either need to have a way to specify the method of tilehandling to use, or you need to call a different handler.
If the TileHandler was passed as a parameter to objects that use it, then you can simply pass a different one next time, or set a different tile handler on objects that use it later.
Personally, I access many things in my XNA games from a static context, and assume that I'll never have more than one of them.
If you want to be able to reuse your game engine code in your next game, you're likely going to have to rewrite much of the stuff that you currently have written as static.
In favor of not using static context:
Passing objects as parameters as much as possible decouples game elements, and allows you to modify/reuse them for the current or future projects more easily. It also allows you to manage the complexity of large amounts of code a little easier (think of having hundreds of static managers in your game class, in a big game).
In favor of static context:
Declaring and accessing objects from a static context makes it easier to write small games that don't require hundreds of static managers. Simplifies many methods and constructors by not requiring one or more extra parameters that are instead accessed statically.