Yes, and yes. Multiple decks and multiple games could be a problem. Whether or not multiple objects would be a problem would depend on where you kept the state. If a Deck object was immutable, meaning once it was created, its state never changed, then you'd not need more than one. But having the Game objects hold the shuffled indexes of the Deck, for example. would introduce strong coupling between the two classes, meaning that even minor changes to the Deck class would probably necessitate changes to Game, too. Having each class keep its own data is generally the best policy.
Also important, further development,
testing, and reuse would be harder.
How would you test your Game class? One way (a currently very fashionable way, although I'm oversimplifying a bit) would basically be to create a MockDeck class which extended Deck and recorded all the method calls sent to it, hand a MockDeck object to the Game in place of a normal Deck, and then checked the logged method calls against what you expected in various curcumstances. Can't do this with static methods.
Having written a proper Deck class, you could reuse it in another card game program. Perhaps you might need to change its behavior a bit: you could do this by extending Deck and overriding one or more methods -- but not if the methods were static.