個人結論：目前，在演示層面，3D Tiles問題不大，但項目應用上就不夠成熟了，所以問問自己，你是想吃瓜呢還是想吃螃蟹？
好的方面
數據規范
我非常喜歡glTF的整體設計，概括有四點：第一，數據塊(Buffer)連續，保證了讀寫性能；第二，提供了視圖（View）和訪問器（Accessor）的概念，在不損失數據塊完整性的前提下提供類型信息和讀取規范，保證了兼容性；第三，邏輯層和數據層分離，兩者盡量分離，比如用戶想要增加一種風格，只會牽連到邏輯層的調整，不會影響數據層的讀寫，保證了獨立性；第四，邏輯層，也就是業務層是JSON形式，保證了擴展性。
3D Tiles在邏輯層，也就是JSON部分增加了FeatureTable和BatchTable，以及LOD(tileset)概念，並對應提供了header(二進制存儲)。從數據規范角度來看，繼承了glTF優秀的部分，同時考慮了傾斜，點雲，后續也會支持OSM，從數據類型的支持上也比較到位。
Cesium渲染調度
目前，WebGL技術+三維球開源框架+大數據渲染，如果拿這三個條件來過濾，除了Cesium並沒有其他選擇，所以這塊要求不能太高。
在這個要求下，通過前兩篇的介紹，Cesium在這塊的框架設計很清晰，基於狀態而不是事件驅動的方式來管理，簡化了代碼復雜度，在邏輯上沒有明顯的沖突。
在代碼設計上，提供了RequestScheduler，管理請求隊列的數量和優先級，debugShowContentBoundingVolume用來查看TileBounds，Cesium3DTileStyle可以通過表達式指定渲染風格，這些產品思路和技術細節都值得我們學習和借鑒的。
tileBounds效果，對開發人員很友好
風格表達式，提供可視化效果
欠佳
LOD
Cesium提供了Add和Replace兩種LOD策略。我認為只需要Replace一種就足夠了，Add是一個雞肋，不能解決大數據下性能的問題，而Cesium偏偏對Replace支持的不好。整個樹結構自始至終都完整保留，卸載時只會刪除數據內容，節點屬性信息仍然存在。另外刪除邏輯過分簡單，某些瀏覽方式下應該會有閃爍問題。
剛才提到節點的屬性信息是初始化一次性加載，如果數據量很大，比如城市級別，這個tileSet會很大很復雜，這點在設計上有點耿直。
數據規范
這個真的是成也蕭何敗蕭何。首先，glTF是針對單個模型的情況，強調數據的完整性，獨立性。但3D Tiles是一個樹關系，每個Tile只是其中的一個Node。打個比方，一棵樹上，節點是葉子，但現在節點對應的是一顆小樹。所以，站在3D Tiles的角度，glTF有很多過度設計的部分。比如shader，animation，scenemanager等，還有紋理部分，不能說做不到紋理公用，但確實在設計上沒有體現。
在渲染調度上，3D Tiles和glTF都是基於狀態，你可以想象，雖然在代碼邏輯上清晰，但在運行時上，對瀏覽器來說是一個負擔。明明一次性能做好的事情，非要分成好幾個任務，還美其名曰敏捷。我覺得一個Tile的解析盡可能在兩個Promise，一個Workers搞定，不拖累主線程，事情也做的干凈利索。
FeatureTable實例化的存儲設計沒有問題，Cesium對應的接口欠妥，要么提供清晰通用的規范，要么只關心存儲結構，讓用戶自己擴展實現實例化部分的Render。
作為一個大數據的數據規范，glTF可以提供壓縮機制，當然Web端解析性能的損耗需要評估，個人認為壓縮的收益太大而無法拒絕。
可用性
缺少免費好用的生成工具，並沒有形成一個成熟的解決方案。基於大數據的擴展能力也很少，只有單體化和實例化，屬性查詢這些基本能力。不知道是否支持2.5維場景，如果能支持，那就牛了。
總體感覺3D Tiles推出的有點倉促，很多地方還需要打磨，感覺戰略壓力大於實際價值，屬於占坑行為。希望后續能夠大力推動，能夠早日有成熟的完整方案和高級功能。
開源
有感於最近的一些親身經歷，也看了看threejs，Openlayers，Leaflet，Echart等項目，也在思考這些優秀的開源項目之所以優秀，到底有沒有一些共性。
就用兩句話來概括：所謂的開源（或規范），不是把自己的東西拿出去，而是把別人的東西拿進來。當我們把一個東西放到github上開源，我們以為這個工作到此結束了，其實它才剛剛開始。
最后，又想到了論語里面的那句“君子務本，本立而道生“，算是從人的角度，對上面兩句話的解釋吧。