Could you please explain why they can't be?

It seems counter intuitive to me. It seems you're saying that static analysis cannot reach every branch of the program (and thus its underlying system libraries).

I'm surely missing something and would be grateful to anyone helping me out!

You can read Chiba's thesis which explains exactly how they are able to detect the systems calls made by the ELF using static analysis and code flow execution analysis (the techniques all seems very simple and ingenious - you can even try to write a little program yourself that uses their algorithm if you don't believe them). The thesis explains that there are edge cases and how they work around them. Remember they have to handle all of the system calls or the program would suffer from run-time errors.

Dlopen allows for dynamic linking of symbols e.g. based on user input or local circumstances (cpu capabilities, type of db being connected to opens a different set of libs for different versions etc.).

You could provide hints for these circumstances, or change a program to work differently to avoid the practice, but having library resolution delayed until runtime and until after the program has started is a real thing.

It is easy to write a function, that makes a syscall directly and not via well known paths in the libc or similar. And then the syscall number can be a variable instead of constant and determining that value statically means solving the halting problem. Q.e.d.

Since conservative approximation is still useful, halting problem doesn't matter.

That is, let's say syscall 1 is definitely used, syscall 2 is definitely not used, whether syscall 3 is used depends on halting problem. Including only 1 and 3 to unikernel is safe and better than including all of 1, 2, 3.

This works in trivial problems. Any moderately sized program I can imagine right now will result in an analysis that is equivalent to "this uses everything"