FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs).

The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release.

And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour.

The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported?

I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.

Because the compiler in base necessarily has the same life cycle as base, while ports lets you rotate new versions in whenever you want.