Not quite.
I'm not discarding the idea of your Roku playing a part in this, but the numbers you've quoted don't bear significance unless you can directly connect them to that *max concurrent* warning, e.g. by means of the logs I suggested to scrutinise (click for details)
You are correct in assuming that using unbound as an upstream recursive resolver along with DNSSEC enabled in Pi-hole may tip the balance for an increased load (as recursion takes longer, and DNSSEC multiplies the number of actual DNS requests Pi-hole would forward upstream).
However, those factors would not come into play for blocked domains, as those are handled by Pi-hole exclusively alone and never forwarded upstream, usually completing in under a millisecond.
When viewed in isolation, your 13 requests per second would roughly translate to one request every ~77ms. But to trigger the warning, DNS requests must arrive faster than Pi-hole can respond to them. For those 13 blocked requests, that wouldn't even happen if Pi-hole would process them strictly sequentially (i.e. with no concurrency at all). Pi-hole would idle for ~76 ms before the next request would arrive.
To reach a volume of DNS queries high enough to trigger that max concurrent warning in that isolated example, your client would have to issue well over 1,000 requests per second - but long before that would have happened, Pi-hole's per-client rate limt of 1,000 requests per minute would have kicked in, and you likely would have noticed a different message instead (e.g. Rate-limiting 10.0.1.39 for at least 44 seconds).
(Of course, that isolated view is not taking into account DNS activity of your other clients, but it should still give you a better idea what's involved)
Often, a DNS loop may trigger excessively high volumes of DNS traffic.
But in your case, we can at least rule out a partial DNS loop caused by Conditional Forwarding, as you've reported that to be disabled.
So without further analysis, we won't know what triggered your warning.
Since analysis of sally's observation isn't complete, I wouldn't be too sure about MrAnderson175's issue being related. For a start, sally's observation does not comprise a VPN, and the device in question is not a smartphone.
While that linked issue produces unwanted log errors, it wouldn't affect DNS processing:
I'm glad if disabling DNSSEC has solved your issue (unbound still does DNSSEC verification in your case, so you don't really lose anything), but that may have been coincidental.