I've done several perf testing runs comparing .NET Core and .NET Framework. I see the interop performance about double in speed (similar to what we were already seeing with UWP's .NET Native runtime), but in grand scheme of things those are very small overheads, so in practice it didn't make much difference in real-world scenarios (as most of the work is actually done in native code, and it is the exact same native DLL being used by both). There might be a few places here and there where you'd see some of .NET Core's new features have an effect, but don't expect to see a huge benefit yet. Also make sure you compare Release build performance.
In addition we're not (yet) taking full advantage of things like Span<T> etc (and neither is the WPF framework), so we potentially have room for improvement, but as mentioned earlier the bottleneck is actually rarely the .NET side of things, so it would really only have limited impact. We're currently having a high priority on performance on the .NET side of things, and diving into various hot-paths and making targeted optimizations where we can, and will use new language features just for the .NET Core build when that makes sense. You should hopefully see some improvements here and there in v100.7, but this is work that we will continue over many releases.
It's hard to rely on DrawComplete and the async set-viewpoint methods for performance testing, as they are timer-based, so even on a slow machine, a zoom is going to take roughly the same amount of seconds (but it might skip some frames and be more "choppy" to keep up), and DrawComplete is unfortunately slightly unreliable right now and might be several frames off. Also your resolution for these tests would be limited to (at-best) the framerate during the operation. Also make sure you perform these tests without the debugger attached.
DefaultConnectionLimit: we default to 6, but will respect it if you set a _higher_ default value (as long as it's not int.MaxValue). Anything beyond 10 doesn't seem to have much effect, but once you do go above 6, you'll start seeing quite a lot of CPU usage, so I really don't recommend changing it (in .NET Framework is 2 and we used to use that. By changing it to 6, we saw about 2.5x improvement on tile loading. Going to 10 was about 3.5x faster, but CPU usage started to spike. Higher than that had little-to-no effect. We settled on 6 as it appears to be the defacto standard and in our testing also showed a good trade-off between performance and CPU usage).
If you have a sample app you can share that shows the differences you experience between .NET Core and .NET Framework, I'd love to take a look. I'd definitely not expect things to run slower (albeit I wouldn't expect it to be much faster either).