I wouldn't call this "normal", but then I rarely use the term "normal" for anything involving MIPs. If the optimal solution from the quick run is close to the best bound from the long run, then yes, this could just be luck (the 14 thread run happened to stumble on the optimal solution quickly). If the 10 day best bound is significantly inferior, then it's a bit less clear that we are looking at luck ... but it is still possible.
Among other things, I think CPLEX will turn several different algorithms loose on the root node in parallel, with whichever one solves the root node first the "winner" (meaning branch-and-cut will use the root solution it got). I'm not sure how changing from 10 to 14 threads would influence that, but you could conceivably wind up with a different initial basis (particularly since your objective function is constant, so all basic feasible solutions are "optimal"). That in turn could result in different cuts and bound tightening results, altering the search tree quite a bit.
Also, the default setting for the parallel mode switch is "auto", meaning CPLEX will choose between deterministic and opportunistic use of parallel threads (with the latter, as you would expect, not being particularly deterministic). You could try running both 10 and 14 threads in deterministic mode (not running the 10 thread version too long, of course) and see if things change.