We're still experiencing the same issue as well with Dspace 6.3 and XMLUI. The workaround that I've been using so far is to create a custom segment in Google Analytics to remove any traffic where the Landing Page is "(not set)". That seems to bring the traffic down to where we would expect it to be prior to the upgrade. I've attached an image of the filter in case it's helpful for anyone.
I've been digging into this recently, and I think that I might know what's behind it. I believe that Dspace 6 was the first version to include Event tracking in Google Analytics (Neha Singh, I think that this might help answer your question above as well). The idea is that every time a document is downloaded, an event is recorded in GA. If I look under Behavior -> Events -> Top Events, it shows a massive amount of download events (61 000 for Sept. 2019 alone), all of which have Homepage = (not set). I originally wondered if this was a bug with the way that Dspace registers events, but when I checked the Dspace Tomcat logs, I discovered that it does appear to be actual download traffic.
To test this, I picked one document which had 1847 download events listed in Analytics over two days in September, and found an almost identical number of bitstream downloads in the logs for those two days. The downloads came from 610 unique IPs, and there were no other downloads in September after the two day flurry. Geographically, 46% of the download events for that item came from Ashburn, Virginia (which apparently suggests that it likely came from an Amazon data center:
https://www.statusbureau.com/analytics-bot-traffic-ashburn/), and the rest were fairly evenly spread throughout the rest of the world. 90% of the download event traffic was direct (not referral, social, or search). Interestingly, the item I chose isn't even a recent upload, it was added to our repository in 2015.