子テーマと重複テーマの名前変更
さて、私は人々が子供のテーマと既存のテーマを変更する代わりにそれらを使用する理由について話すのをよく見るが、彼らは皆親テーマが更新されるなら全ての変更が失われるという考えの中心にあるように思われる。私が過去にサイトを作成したとき、私は常に最初のテーマの複製を作り、style.cssの中のテーマ名を変更し、そしてそこで直接働きました。子テーマの代わりに単一テーマを使用すると、オーバーヘッドが節約され、コードをより細かく制御できるようになります。たとえば、不要な機能を回避するのではなく削除します。私が問題に遭遇した場合、私は常に参照する元のテーマファイルを持っています、そして親テーマが更新されたとしても、関数名やそのような変更があったとしてもやはり私の子テーマは壊れます.
私のWeb検索では、このトピックに関してあまり「開発者の好み」を保存していませんでしたが、これは実際のところ理由ではありません。
テーマを複製して名前を変更するよりも、子テーマを使用することの本当の利点はありますか？
子テーマは、主にテーマのスタイルを変更したいが、基礎となるコードを維持したくない、またはその方法を知りたくないユーザーにとって便利です。 PHP/WordPressテーマ開発のコークは、CSSのコークとはまったく異なるものです。
子テーマは、テーマに小さな機能上の変更を加えたいユーザーにとっても便利です。これは、アクション/フィルタフック、プラグイン可能な関数など、修正のための多くの手段を提供するテーマに特に役立ちます。もちろん、そのようなmodはカスタムプラグインを介して簡単に実装できますがこれはアクティブなので、このコードを子テーマに配置するのと同じくらい意味があります。
フォークされたテーマを維持することに慣れていて、あなたの修正が子テーマにとって合理的であるものを超えていることがわかったなら、ぜひともテーマをフォークしてください。
それはすべて個々のエンドユーザーにとって最も有益な方法になります。
チップベネット回答に加えて
私自身のような開発者の中には、独自のカスタムフレームワークを持っているか、GenesisやHybridなどのようなものを使用しているものがあります。 CPTやCTの基本クラス、メタボックスライブラリ、cssフレームワークなどもあります。すべてのコードを別々のリポジトリに保存し、それらを「テーマ」にまとめてからそれらの部分を子テーマに使用するほうが簡単です。
私の場合、私のframework/library/parentテーマは私のライブラリパーツのロードメカニズム、私のフックとテンプレーティング、そしてブートストラップ関数以外何も持っていません。子テーマでは、特定のタスクに必要なものを定義したり、単一のタスクモジュールを追加したり、親基本クラスを拡張したりできます。最後に重要なことを言い忘れましたが、Child Themeには、私のすべてのUIパーツ（スタイル、スクリプト、イメージ）が含まれています。
ですから、私や他の多くの開発者にとっては、物事を一般化し、整理し、再利用可能な状態に保つための良い方法です。
子テーマの最大の用途の1つは、MUWPインスタンスです。多くの場合、マルチサイトインストールでは、関連サイトがテーマの一部またはほとんどを共有しますが、カスタムページレイアウトまたは要素スタイルを設定する必要がある場合があります。この場合、子供のテーマを使うのは理にかなっています。同じテーマの要素は親テーマ（実際のところ、重複するデフォルトテーマに基づくカスタムテーマの場合もあります）で扱われ、異なる必要がある要素は子テーマで扱われます。
子テーマの利点は、子テーマと親テーマの唯一の違いが、子テーマ自体に明確に見られることです。親と子のテーマの違いを知りたいですか？子供のテーマ自体はそれらの違いの合計です。子供のテーマを変更する必要がありますか？テーマ全体のコードを読み進めるのではなく、いくつかの規則と機能を調べるだけで済みます。