People with access to change systems have access to crash systems. This is fairly true across all tech, and all you did was prove it for Redshift. I think what you are missing is that for it to be a vulnerability, it would need to be something that extends that ability to do damage beyond your current scope. If you can crash someone else's cluster, that is a vulnerability. But not if you can only crash your own.
I'd double check whether a denial of service is out of scope, it often is.
Additionally, I'm not intimately familiar with Redshift, but being able to create a table suggests the attacker would already need a fairly high privilege level to begin with, no? If there are other ways to invoke denial of service conditions from that existing privilege level, this finding may be somewhat moot out of redundancy, similar to how a submission for "a root user with the ability to execute arbitrary commands can cause a denial of service condition in XYZ" would be moot - XYZ is not needed for an adversary with those perms to cause a DoS.