DNSSEC: Spotify and Apple podcasts on iOS

If you'd switch off Pi-hole, you would have no DNS resolution at all (unless your router would cater for an alternative DNS server somehow).

I think you mean that you use Pi-hole's web UI to Disable Pi-hole:
Disabling Pi-hole won't cut DNS resolution; it will just stop Pi-hole from filtering requests. The behaviour is the same as running Pi-hole completely void of blocklists, white- and blacklists.

INSECURE results mean that Pi-hole could not employ DNSSEC to validate the domain because required respective DNSSEC related records are absent from somewhere in the validation path, i.e. the domain does not support DNSSEC validation.
This does not affect DNS resolution, Pi-hole will still supply the requested DNS records to the client.

Beyond the current log, you may search all available logs for BOGUS answers by running:

zgrep -n BOGUS /var/log/pihole.log*

It currently seems that you cannot correlate blocked or BOGUS replies with your client's inability to stream from Spotify.
As you observe no matching BOGUS replies, that would make an issue with a misconfigured authoritative DNS server less likely.

Your debug log contains quite a few instances of the following lines:

*** [ DIAGNOSING ]: contents of /var/log

-rw-r--r-- 1 pihole pihole 129K Apr  9 15:45 /var/log/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2022-04-09 00:00:20.500 26610M] ERR: Port mismatch for 9.9.9.9: we derived 53, dnsmasq told us 48
   [2022-04-09 00:00:20.500 26610M] ERR: Port mismatch for 5.9.164.112: we derived 53, dnsmasq told us 48

This same symptom has been reported a while ago, and it's woth noting it has some ties to DNSSEC.
Past analysis then concluded that while the message was logged, Pi-hole's DNS resolution would still be operational, as pihole-FTL can still acquire the correct port.
Nevertheless, that the Pi-hole team developed a fix for that issue (but also, dnsmasq would have to do some patching for its part).

You could try to use Pi-hole's fix and see if that would have an impact on your issue:

BUT BEFORE DOING SO:
Could you please extract sample portions of your /var/log/pihole.log as well as corresponding /var/log/pihole-FTL.log for the time when you fail to stream from Spotify?

This may help Pi-hole development to check if there would be any abnormalities beyond the Port mismatch warnings that potentially would explain your observation.

If you prefer, you may upload your logfile portions to Pi-hole's tricorder by running e.g. (assuming you've stored your excerpt to a file pihole.partial.log):

cat pihole.partial.log | pihole tricorder

Then provide us with the respective tokens as shown once the upload completes.

And finally, and again unrelated to your observation: (click for details)

From your debug log

-rw-r--r-- 1 root root 1,2K Apr  2 13:04 /etc/pihole/pihole-FTL.conf
   ; Am 2017-06-19 manuell erstellt und Konfiguration gem. https://github.com/pi-hole/FTL#ftls-config-file vorgenommen/angepasst
   TIMEFRAME=rolling24h

That option is long deprecated and has been removed from Pi-hole in January 2018. Pi-hole's rolling 24 hour timeframe has become the fixed, unchangeable default.