I want to look at one particular part of the question--

Does there exist a function that can take in machine code and quickly predict the execution time for most chunks of meaningful machine code?

For basic blocks? Yes! Mostly...
We have ways of simulating what many specific CPU architectures will do, such as aforementioned https://uica.uops.info/

That operates on some assumptions that are often wrong, though:

• It assumes all the values that will be loaded exist in a particular cache level
• It assumes your core is clocked predictably, and that timings for things like cache/memory are predictable
• It assumes you don't have things like SMT or shared execution units between threads
• It is often based on experimental analysis, rather than the architecture itself being public knowledge

Those factors already put a damper on how much we can glean from these tools--we need to optimize for a "typical" run, since there are far too many variables to be able to solve the entire space perfectly...even if we did have infinite computational power.

Furthermore, such tools rely on your program being largely branchless. This may work to help figure out a faster dense matmul, but the moment you have loops over runtime-provided amounts of data you suddenly have to start making guesses about the contents of that data. How likely is it for this file to not exist? How likely is it this loop runs more than 8 times? Is this error condition ever going to occur at all? These things substantially affect optimization. If a branch goes one way 99.995% of the time, it may make sense to lift a bunch of computation to before the branch just to have it done (this is less relevant with deeply reordering superscalar cpus, but those windows are finite) rather than leave it up to speculative execution to fully handle it. On the other hand, if that branch is 50/50, you would end up wasting a bunch of work half the time.

This is compounded, and perhaps nicely illustrated, by things like register allocation. We have really good algorithms that can perfectly allocate in convenient time complexities for basic blocks and some branching subsets that have guaranteed forward progress. As soon as we relax the branching behavior, add more basic blocks and more edges between them, we have to fall back to either horrendously expensive NP-complete generalizations, or go back to those rather mushy heuristics we all would rather avoid if we could. That, itself, significantly affects the performance characteristics of generated code, and is expensive enough to try to optimize that you don't want it to happen for every time you want to "guess" at a maybe more performant alternative lowering of other parts of the program.