Bad is bad - 'nuff said!
“But” = I hear you but am not listening and will disregard because I can! (or that is how it reads)
If you live >50miles from any other potential user - now or in the future then go ahread, knock yourself out but if you are near others simply put dont be knowingly antisocial wrt TTN use. (Where in the world are you) Your short (intermittent) test - a few hours? a few days? a month? a year can be someone elses critical testing phase and may screw what they are trying to achieve.
I know from bitter experience as last year whilst doing a follow up test deployment for a local council after a short coverage check a few weeks earlier I ended up £thousands out of pocket due to over running engineering/on site test time & detailed coverage check and diagnostic activity with hotel bills & subsistance costs for contractors/staff. An early quick and dirty test had indicated existing coverage in some areas from a couple of known & stable GW’s , so we used available budget to look to add a few additional GW’s in key strategic coverage locations and a few infill places. The GW’s were initially put in on temporary basis to check coverage and overall reception and to ‘prove’ the viability of planned use cases over a number of weeks, then critically once client was satisfied we went to deploy permanently, with some minor site adjustments. At the end of the few days work as we were finishing/commissioning and confirming coverage/operation the client complained we were starting to see missed packets, slower than expected join processes and two sites where the node would occasionally ask for confirmed downlink or would expect a command return for end equipment on/off enabling which would either not see action or would have a very long response latency (many minutes even hours before action). We had to stay on site for an extra couple of nights and ~2.5 day longer whilst we monitored and debugged the situation.
It turned out some bozo had deployed an intermittently used SCPF (suspicion was there might have been 2 in close proximity) that was screwing with the real system 
Ironically it was on when we did the initial quick and dirty coverage/planing test and appeared to help (uplink) coverage. It appears it was off for the time we deployed on temp basis and for most to the eval trial before full deployment and was turned on again sometime before or during the final install period and for the commissioning checks. We obviously were initially confused by what we were seeing until the SCPF was spotted in the packet metadata for a few hours, and the penny dropped, then we could focuss evaluation and mitigation efforts. We ended up re positioning one of the infill GW’s to ensure our nodes were heard directly with better coverage than through the SCPF as mitigation and that seemed to solve the problem to better stats than we could reasonably meaure in a short test period so client was happy. To play safe we sent them an additional low cost infill GW to deploy in the area as a back up a few weeks later and there have been no reported issues since.
As you might expect there is now a systematic search & check for SCPF’s operating in the area for any subsequent test deployments 
If we find problems start being reported by a client that is now one of the problem generators we start to look for. Better if we never had to deal with such situations and certainly dont want to encourage any more deployments - hence a passionate poster on the subject on the forum. Fully understand and appreciate the historic reasons for the early use of such devices but there is now no excuse given the relative low cost of micro GW’s (and yes I include the TTIG here despite some reservations as also called out by others - these usually affect ability to uplink vs downlink and therefore do not cause all the problems associated with a SCPF, even better to have ~99% packet del’y than <30% (<10%?) c/w SCPF’s 
- should be fine once natively supported in V3 vs current bridging kludge )