マテリアルに限らず頂点・面・オブジェクトいずれもですが、num****は「配列のサイズ」を返します。
deleteは配列内の要素をNoneに置き換えるだけで、compact処理により配列の切り詰めが行われるまで配列数は変わりません。
（※compactはSDKには存在しますがPythonには提供されていません）
そのため、サンプルで必ずしているように各要素がNoneかどうかをチェックしながら処理する必要があります。

了解です。確かにプラグインSDKドキュメントにはその旨記載されていました、失礼いたしました。つまりMetasequoiaのリストビューには非NULL（非None）のオブジェクト・マテリアルのみが表示されている、ということですね。オブジェクトに関しては削除のたびに毎回Compactionが実行されるようですが……
ちなみにMQDocument.numObjectやMQDocument.numMaterialは、len(MQDocument.object)やlen(MQDocument.material)で求められるので、特に必要ないと思うのですが、何か理由があるのでしょうか？　スクリプトヘルプには「オブジェクトの数」「材質の数」と記載されているだけなので、一見しただけではGUIのビュー側と食い違っているように見えてしまい、直感的でないと思います。

そのほか、Python関連の別件として、4.5.3本体ヘルプの「スクリプトエディタ」には「Pythonのバージョンは3.3.5となっています。」と記載されていますが、「バージョンアップ履歴」を見るかぎり、Metasequoia 4.5以降のPython対応バージョンは3.4.3ではないでしょうか？

PythonはSDKに比べるとドキュメントの整備が追い付いていないこともあり、
この配列問題以外にも注意点が十分に記載されておらずご迷惑おかけします。

numObject/numMaterialが存在する理由は２つあります。
len(MQDocument.***)を使う場合、都度
・配列の作成
・lenの呼び出し
・配列の破棄
が行われてオーバーヘッドが大きく、
一方num***プロパティの場合は呼び出しのみなので、こちらのほうが効率的に実行することができます。

もう一つの理由としては、C言語ベースのSDKの関数をほぼ1:1となるよう単純にPythonの関数・プロパティに置き換えたためです。
Pythonにイテレータが搭載されるかされないかくらいの時代に対応したこともあって、
今どきのPythonに慣れた人が繰り返し処理によく使うような記述とはやや異なっているかもしれません。

>Metasequoia 4.5以降のPython対応バージョンは3.4.3ではないでしょうか？

ヘルプの記載を更新し忘れていました。
Ver4.5.0からPython3.4.3に変更されています。
この間で互換性が問題となるケースはかなり少ないとは思いますが、
今後も定期的にPythonのバージョンは新しいものに更新していきますので、
新しめのバージョンで搭載されたモジュールを使う場合などは互換性にご注意ください。

詳しい解説をいただきありがとうございます。歴史的な経緯もあるということですね。通例Pythonにおけるlistのコピーは参照のコピーのはずなので、コピーに関してはそこまで大きなオーバーヘッドではないと思うのですが、MQDocument.objectやMQDocument.materialに関しては使用したタイミングでディープコピーが発生するということなのでしょうか？
ヘルプの更新のほうはお手数ですが随時対応をお願いいたします。本格的にPythonを使用する方々はリリース履歴やDLLバージョン情報も事前に調べるとは思いますが。