In short, whenever you use "new", you are tightly coupling the class containing this code to the object being created; in order to instantiate one of these objects, the class doing the instantiating must know about the concrete class being instantiated. So, when using "new", you should consider whether the class in which you're placing the instantiation is a "good" place for that knowledge to reside, and you're willing to make changes in this area if the form of the object being instantiated were to change.
Tight coupling, that is an object having knowledge of another concrete class, is not always to be avoided; at some level, something, SOMEWHERE, has to know how to create this object, even if everything else deals with the object by being given a copy of it from somewhere else. However, when the class being created changes, any class that knows about the concrete implementation of that class must be updated to correctly deal with that class's changes.
The question that you should always ask is, "Will having this class know how to create this other class become a liability when maintaining the app?" Both major design methodologies (SOLID and GRASP) would usually answer "yes", for subtly different reasons. However, they are only methodologies, and both have the extreme limitation that they were not formulated based on knowledge of your unique program. As such, they can only err on the side of caution, and assume that any point of tight coupling will EVENTUALLY cause you a problem relating to making changes to either or both sides of this point. You must make a final decision knowing three things; the theoretical best practice (which is to loosely-couple everything because anything can change); the cost of implementing the theoretical best-practice (which may include several new layers of abstraction that will ease one type of change while hindering another); and the real-world probability that the type of change you are anticipating will ever be necessary.
Some general guidelines:
Avoid tight coupling between compiled code libraries. The interface between DLLs (or an EXE and its DLLs) is the main place where tight coupling will present a disadvantage. If you make a change to a class A in DLL X, and class B in the main EXE knows about class A, you have to recompile and release both binaries. Within a single binary, tighter coupling is generally more permissible because the entire binary must be rebuilt for any change anyway. Sometimes, having to rebuild multiple binaries is unavoidable, but you should structure your code so that you can avoid it where possible, especially for situations where bandwidth is at a premium (like deploying mobile apps; pushing a new DLL in an upgrade is far cheaper than pushing the entire program).
Avoid tight coupling between the major "logic centers" of your program. You can think of a well-structured program as consisting of horizontal and vertical slices. Horizontal slices may be traditional application tiers, like UI, Controller, Domain, DAO, Data; vertical slices might be defined for individual windows or views, or for individual "user stories" (like creating a new record of some basic type). When making a call that moves up, down, left or right in a well-structured system, you should generally abstract said call. For example, when validation needs to retrieve data, it should not have access to the DB directly but should make a call to an interface for data retrieval, which is backed by the actual object that knows how to do this. When some UI control needs to perform advanced logic involving another window, it should abstract the triggering of this logic via an event and/or callback; it doesn't have to know what will be done as a result, allowing you to change what will be done without changing the control that triggers it.
In any case, consider how easy or difficult a change will be to make, and how likely said change will be. If an object you are creating is only ever used from one place, and you do not foresee that changing, then tight coupling is generally more permissible, and may even be superior in this situation to loose coupling. Loose coupling requires abstraction, which is an extra layer that prevents change to dependent objects when the implementation of a dependency must change. However, if the interface itself must change (adding a new method call, or adding a parameter to an existing method call), then an interface actually increases the amount of work necessary to make the change. You have to weigh the likelihood of different types of change impacting the design, and it will be infeasible or even impossible to make a system that is closed to all types of change.