これは、Ketanとdaniel kullmanの回答、および私自身の調査から得られた完全な回答です。
「機能」のほとんどはクエリの最適化であることがわかります。これfindは、一般に、ファイルシステムで（ほぼ）任意に複雑なクエリを実行できるためです。
D_TYPE
D_TYPE機能の存在は、findのd_typeフィールドのサポートを使用してコンパイルされたことを意味しstruct direntます。このフィールドは、Linuxでも採用されているBSD拡張であり、から返される構造にファイルタイプ（ディレクトリ、ファイル、パイプ、ソケット、文字/ブロックデバイスなど）を提供しますreaddir。最適化として、findこれを使用して、をフィルター式として使用するlstat場合に呼び出しを削減または除去できます-type。
readdird_type一部のファイルシステムでは常に生成されるとは限らないため、場合によってlstatはまだ必要です。
公式ドキュメントの詳細：https : //www.gnu.org/software/findutils/manual/html_node/find_html/d_005ftype-Optimisation.html
O_NOFOLLOW
このオプションは、(enabled)またはのいずれかを読み取ります(disabled)。この機能が存在し、有効になっている場合、この機能findは特定のTOCTTOUレース攻撃から保護するセキュリティ対策を実装します。具体的には、findディレクトリトラバーサルの実行中にシンボリックリンクをトラバースしないようにします。これは、ディレクトリのファイルタイプがチェックされた後、ディレクトリに入る前にディレクトリがシンボリックリンクに置き換えられた場合に発生する可能性があります。
このオプションを有効にfindするとopen(..., O_NOFOLLOW)、はディレクトリでを使用して実際のディレクトリのみを開き、次にを使用openatしてそのディレクトリ内のファイルを開きます。
LEAF_OPTIMISATION
findサブディレクトリは（..リンクを介して）親のリンク数に影響するため、このわずかにあいまいな最適化により、親ディレクトリのリンク数を使用して、親ディレクトリのどのサブディレクトリがディレクトリであるかを推測できます。特定の状況ではfind、statコールを回避することができます。ただし、ファイルシステムまたはOSがを誤って表すと、偽の結果が生成さst_nlinksれる可能性がありfindます（これは非常にまれに発生します）。
公式ドキュメントの詳細：https : //www.gnu.org/software/findutils/manual/html_node/find_html/Leaf-Optimisation.html
FTS
このFTS機能を有効にすると、直線的な再帰的な実装ではなくfind、ftsAPI を使用してファイル階層をトラバースします。
利点が何であるかはわかりませんftsが、FTS基本的に、findこれまでに見たすべてのデフォルトバージョンのデフォルトです。
さらに詳しい情報：https://www.gnu.org/software/findutils/manual/html_node/find_html/fts.html、http://man7.org/linux/man-pages/man3/fts.3.html
CBO
（findDaniel Kullmanの提案に従ってソースコードを読んだ後） "CBO"はクエリの最適化レベル（ "コストベースのオプティマイザ"を表す）を指していることがわかります。たとえば、私が行う場合find -O9001 --version、私は得る
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=9001)
の-Oオプションman findを見ると、
-Olevel
Enables query optimisation. The find program reorders tests to speed up execution while preserving the overall
effect; that is, predicates with side effects are not reordered relative to each other. The optimisations performed
at each optimisation level are as follows.
0 Equivalent to optimisation level 1.
1 This is the default optimisation level and corresponds to the traditional behaviour. Expressions are
reordered so that tests based only on the names of files (for example -name and -regex) are performed first.
2 Any -type or -xtype tests are performed after any tests based only on the names of files, but before any
tests that require information from the inode. On many modern versions of Unix, file types are returned by
readdir() and so these predicates are faster to evaluate than predicates which need to stat the file first.
3 At this optimisation level, the full cost-based query optimiser is enabled. The order of tests is modified
so that cheap (i.e. fast) tests are performed first and more expensive ones are performed later, if neces-
sary. Within each cost band, predicates are evaluated earlier or later according to whether they are likely
to succeed or not. For -o, predicates which are likely to succeed are evaluated earlier, and for -a, predi-
cates which are likely to fail are evaluated earlier.
The cost-based optimiser has a fixed idea of how likely any given test is to succeed. In some cases the probability
takes account of the specific nature of the test (for example, -type f is assumed to be more likely to succeed than
-type c). The cost-based optimiser is currently being evaluated. If it does not actually improve the performance
of find, it will be removed again. Conversely, optimisations that prove to be reliable, robust and effective may be
enabled at lower optimisation levels over time. However, the default behaviour (i.e. optimisation level 1) will not
be changed in the 4.3.x release series. The findutils test suite runs all the tests on find at each optimisation
level and ensures that the result is the same.
謎解きました！オプションがランタイム値であることは少し奇妙です。通常、--version出力にはコンパイル時のオプションのみが反映されると思います。