As Raymond Chen wrote, that's the other side of the airtight hatch (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...).
If someone is capable of directly running their own code that ignores libc (or other existing mitigations, such as may exist in javascript runtimes / go compiler) then cool, they can use spectre to perform a timing attack against their own code that they're running. Or they could just read their own memory.
Spectre's main risk was for reading other program's memory or for doing so remotely with javascript. If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help.
You're basically arguing that in a post-spectre world, native processes can fundamentally never be a security boundary again, right?
I'm wondering if this is necessarily true. For the concrete example at hand, Linux could offer some opt-in mechanism, e.g. an argument to exec(), that restricts syscalls to glibc only. A sandboxing mechanism could then require all executed processes to go through glibc and instantiate them only using that option.
If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc.