It says "usually". It varies! But, in general, the libc implementations I have looked at handle this. This includes Newlib, glibc (they call it start.s), picolibc, musl (crt1), and my own libc.
The presence in your binary only means that crt0.o was statically linked (may be an expectation of the loader on your system). If you linked against a static libc, you would also see those symbols as part of the binary.
I think your last paragraph is wrong. crt0.o is static even when linking to libc.so dynamically. The ELF format has something in the headers for an entry point which will point at _start in your own binary, not in libc.so.
I'm pretty sure it works that way on windows too, but they call the symbol mainCRTStartup or some such.
The point I am making is that crt0.o usually comes from libc, even if it is linked separately.
I suspect that the loader expects the ELF entry point to be an address in the application, not a dynamically linked library, which is why crt0.o must be statically linked.
The presence in your binary only means that crt0.o was statically linked (may be an expectation of the loader on your system). If you linked against a static libc, you would also see those symbols as part of the binary.