First thing I'd do is figure out what that latch is. Quick google brought me to this:
This latch class is when a thread is waiting for access to the structure that controls a running DBCC consistency check.
So, to me, that wait is due to a DBCC CHECKDB call. The numbers, if I remember right, are NOT the "currently running wait" metrics, but the metrics since the server was started.
What I'd be doing is looking at the execution plan to see if the estimates and actual values are similar as my first step. If they are similar enough, then statistics are likely not the problem. Next, I'd be checking for blocking while that query is running. If no blocking is happening, my next thought would be to check on server resources. Does the CPU or memory spike while that 10 second/4 minute query runs?
Another thing to look for is the antivirus. If it is scanning on file changes, the database files may need to wait for the AV to finish its scan before it can do any writes to the database.
To test if it is the network causing problems, run your 4 minute query directly on the database (ie localhost rather than over the network). If it comes back in 10 seconds, the it is likely network causing the slowness. If it still takes 4 minutes, then it is likely not the network.
But it could be any number of things. Your new hardware MAY have worse single-core performance which may make your queries slower. The server may have more stuff running on it than the old one, so even though it is "beefier", it may have fewer resources for SQL. Could be bad statistics. I would also check sp_who2 to see if anything is running CHECKDB that you are not aware of.