The filesystem will be available with smbd on the client computers. Does this miss some important feature of btrfs? (apparently root has ssh access to the NAS for operations on the btrfs filesystem).
By default Btrfs will just function like any other filesystem. It has features that a SMB server might want to make use of, but they're optional.
For example, with Samba, you might want to enable the 'btrfs' module in vfs objects = in order to gain support for server-side copy using reflinks (i.e. clients being able to ask the server to copy remote files from one folder to another without having to download and re-upload them).
Samba also has the 'snapper' and 'shadow_copy' VFS modules for integration with Btrfs snapshots made by Snapper; it can make them visible as "Previous versions" on Windows clients (like Volume Shadow Copies on a Windows-based file server).
I have heard that it is a versioning filesystem. Git comes to mind.
It's similar in some ways, but not really the same.
Btrfs supports snapshots which are similar to Git commits, but it does not intend to keep a permanent log of all versions – past snapshots can always be deleted to reclaim space. (For example, tools like Snapper can be configured to keep daily snapshots for a month, but to start pruning them as they get older.)
If I delete a file, can I find it again with 100% success?
Only if you still have an earlier snapshot made before that file was deleted.
If there are no more references to a file, it's gone – its disk space is "freed" and becomes eligible for reuse, just like on any other filesystem.
This is similar to Git behavior, where objects do get garbage-collected if nothing references them anymore (e.g. when you amend a commit, the old one becomes eligible for GC; when you delete a branch, all commits and files that were unique to that branch are eventually GC'd and disappear).
I've heard that even if the cumulative size of all files is 5TB, the 18TB free space will soon run out due to versioning and that root commands are required to free it (probably a compaction with deletion of previous snapshots, if I understand correct). Does this apply?
Not by default, no. Old versions of files are not kept unless you create a snapshot deliberately.
Although Btrfs is a "copy on write" filesystem where each change to a file allocates new space (instead of overwriting the file in-place), this is very temporary – as soon as the new write is committed, the old version of those sectors is forgotten and the same amount of space is reclaimed (unless a previous snapshot still holds a reference to it).
So you would only run out of space if you 1) create frequent snapshots and 2) have large files that frequently change between snapshots (e.g. highly-active databases or VMs, or downloads that remain in old snapshots after being deleted). Snapshots of unchanging files consume little to no additional space, while updates to non-snapshotted files release previously used disk space as soon as the new version is stored.
Note that Btrfs on its own does not create snapshots automatically – you have to deliberately run btrfs fi snap or set up tools such as Snapper or Timeshift to make it happen, so those tools become responsible for automatically deleting old snapshots as well (according to your set rules).
That being said, the "copy-on-write" nature of Btrfs does rely on there being some amount of free space to process even deletions (as those require writing new metadata). Usually Btrfs keeps a certain amount of free space in reserve so that you'd still be able to delete things even at 100% capacity, and has over time gotten better at handling "no space" situations, but historically it was known for its tendency to become wedged in a difficult to fix state after hitting ENOSPC.
Also, while COW doesn't eat up space, it does have the disadvantage of increased fragmentation of frequently-updated files (and metadata). In other words, yes, "disk defragmenting" exists on Linux.
