When messing around with tiny hand-written assembly language programs, yeah it's 100% normal to say whether you're building a dynamically linked executable out of it or not. (Because a static executable is a very real possibility, so this is a special case of what @pjc50's answer mentioned.)
For example, in a dynamically linked executable, glibc's init hooks get called by the dynamic linker, so it's already initialized before execution reaches _start in the main program. So it can call printf even with a hand-written _start that doesn't call libc's init functions. (This is not something you should rely on for production use, but it is true on GNU/Linux. But not Cygwin glibc; I don't know why they don't take advantage of that.)
There's also ELF executable (ET_EXEC) vs. ELF PIE executable which is actually a "shared object", the same ELF type as a shared library. Most distros have configured GCC with -fPIE -pie as the default for several years now (https://stackoverflow.com/questions/43367427/32-bit-absolute-addresses-no-longer-allowed-in-x86-64-linux). Position Independent Executables (PIE) take advantage of the kernel and toolchain's support for an ELF shared object to be executable and have an INTERP field the same as an ELF executable (specifying a dynamic linker path, like how a text file can have a #!/bin/sh line specifying an interpreter.) Having an interpreter is what most people mean when they say "dynamically linked", even if there actually aren't any shared libraries that need to get linked.
file used to report PIE executables as "shared object" because that's what they were. They make ASLR possible, so that silly computer trick became a mainstream use-case. These days file identifies them as ELF 64-bit LSB pie executable (on my x86-64 desktop for example).
You can even have a static PIE, which ld and gcc won't create by default, only if you specify -static-pie, not -static -pie where -static overrides -pie.
