來這裡問大家的用意(目的)是......?
(若單純是求知, 那就不用看下面了)

我們說你不對:
你摸摸鼻子, 回去不爽, 也不想改; 就算改了, 心裡也是個疙瘩...

我們說你很對:
你有辦法拿我們的回答, 去跟廠商正面對抗嗎?
你叫廠商改, 人家兩手一攤不做了, 誰要扛責任?

我在大型組織內也常遇到這樣的情境: 工程師很堅持要在同溫層得到「專業正義」, 但當他得到正義方的支持之後, 請她走出同溫層, 去進行商業溝通的時候, 又通通縮回去了....

這樣, 你堅持來的正義, 要如何伸張到對方的領域去?

回到這題來, 如果你在這裡得到的答案, 是建議:
只能放 /opt, 不可放 /usr 的話

若我是廠商, 第一個會跳出來問:
1.這是誰說的?
2.誰有權決定?

我會把球拋到此案的 Owner 身上, 這時候要看你們的場景中, 誰是 Project Owner (PO)? 這個 Owner 是不是願意支持你的決策? 我能不能對 Owner 施壓, 做出對我有利的決定?

如果商業施壓的成本, 低於我(廠商)修改路徑的成本, 我就會選擇走施壓這條路.

一萬個網友說應該要左轉, 負責此案的 PO 仍然可以右轉, 因為扛責的是他, 不是網友.

我可以給你一些觀念
usr 這個目錄很萬能的。
但其實這個目錄放的就是非主核心安裝、外加的套件軟體等等。
都會放在這個目錄上。

所以一整套跟其有關的套件，都會放在這裏。
其也可能會包含資料等相關數據。

像某些 mysql 的 data 有些套裝也是直接放在 usr/mysql/data 內的。

雖然不能說你的觀點是錯的，但其實也是不能說你對。

一般資料化的東西。不是在 var 就是在 usr 內。這點很正常。
至於你說的opt。理論上來說。資料是不該放在這裏的才對。

opt理論上來說，很像是 usr 的延伸體的東西。
所以說要放data相關的東西在這也還沒關係。
但單純純data直接放 opt 上其實也不太對。
它是要有附屬的特性才會將資料放到 opt 上的。

opt的東西，會比較偏向為給某一個主應用的附屬應用來放的。
如早期的PHP多版本的應用。大多都是放到 opt 上。
而var上還是會有一個主PHP。

有點離題了。
總之，廠商將資料放到 usr 上，其實是沒毛病的。
之前 mysql 也是放在這裏啊。

但如果你看不慣，你可以用連結特性去做轉向不就好了。

有需要這麼堅持嗎?
我會關注其它更重要的事項，如:系統功能、穩定度、備(份)援、資安防護...等等。
真的沒東西可以搞了，才會來討論這部分。