The current state of Spectre, Meltdown, L1TF, SRDBS, etc. on most platforms, with all patches applied and default mitigations enabled, is that attacks across security boundaries (e.g. cross-core, cross-VM, cross-process) are either impossible or highly impractical. On virtualised hosts, an up-to-date virtualisation platform (e.g. ESXi, Xen) should apply strong mitigations to cross-VM attacks as long as CPU microcode updates have been performed.
When it comes to checking the state of these issues on a host, this sentence is really the crux of it:
However, protecting against known implementations of the exploits might not necessarily mean I am fully protected.
Your VPS provider appears to be running RedHat's own detection script. This is probably fine, but I can't find a public copy of that script, and RedHat require a subscription to download it. As such, it may just be checking for kernel patches.
I would recommend asking your hosting provider to run spectre-meltdown-checker, which checks the status of the CPU in a platform-agnostic way, and looks for OS patches and mitigations. The methods are publicly documented. Having good results from both the RedHat script and the open source script is about as much assurance as you could hope for.
More generally speaking, you should be mostly protected against known CPU side-channel attacks on an up-to-date version of RedHat. The OS will apply mitigations by default and the VPS provider would have to turn them off to leave you vulnerable - something that's not in their interests to do as a virtualised hosting provider.
An attacker who executes untrusted code in the context of a process may still be able to exploit some of these attacks, to varying degrees, but they will generally only be able to recover information from that process. The microcode updates offer some protection against cross-core attacks, and the OS patches mitigate the cross-process side of the vulnerability by being careful to flush caches during context switches across security boundaries. In a server environment there are few (if any) cases where untrusted code executes in the same process as trusted code, and if an attacker can gain unrestricted arbitrary code execution in the context of a process on the server they aren't likely to bother with a side-channel attack.
The main scenario that people worry about with Meltdown and Spectre, outside of the VPS space, is browsers, since you have multiple documents from different origins running untrusted code (e.g. JavaScript) alongside each other, often in the same process. If an attacker can exploit a side-channel attack from JavaScript (which is entirely possible, and has been done) they can use it to get access to process memory. If multiple documents from different origins are loaded into that same execution context, they can access resources from those other documents and violate the same-origin policy (SOP). This is why SharedArrayBuffer is restricted behind COOP/COEP - it is highly useful as a primitive for exploiting these issues, so browsers require that any resource that wants access to that primitive must be isolated in its own process.
All in all, I wouldn't worry too much. Your average attackers don't tend to use this stuff, and even the more advanced ones (which you generally shouldn't worry about unless you're an MSP, NGO, CNI, TLA, gas & oil company, or global comms provider) don't bother unless there's a major reason to. There are only a few odd scenarios where side-channel attacks like this are relevant against a server instead of a client browser.
The TL;DR - try to ensure that patches are applied, but don't focus time and attention on this stuff to the detriment of more likely attack vectors such as outdated packages, webapp bugs, config issues, information exposure, poor quality firewall rules, etc.
