TBX is a proprietary Microsoft OLE2.0 (or as they later named it Compound File Binary File Format). But it is a legacy now; Microsoft had changed from .doc to .docx and .xls to .xslx. These old formats (OLE2.0 based) are legacy now for more than 10 years, while docx and xlsx are a set of XML files compressed into a zip file.
Link: List of Microsoft Office filename extensions - Wikipedia
For me, representing developers' viewpoint, the legacy is not the main issue.
The biggest issue is that TBX-s is binary format that can't be efficiently used in a development as it exists today. When developer teams are developing different features on different source control (git, tfs to name a few) branches at some point we do merges from several branches into one for the next release the issues with "shared" TBX-es begin. If branch1 got a new tool in common.tbx and branch2 got another one then merge is impossible as TBX is binary format. So we need to solve such conflicts manually. OK, cooperation between the teams is not a bad thing, but...
We can't track differences between "spring release tbx" and "autumn release tbx". We can't see textual diff-s which is essential for finding such issues as what changes could break this version.
So my suggestion is to change to zip with open specification what it should consist: manifest, content, python scripts (and optionally CLSIDS of COM classes, but that's ArcMap world and I do not expect this idea will happen here).
The main wish is to have a set of text files that can be (essential is development with version control) compared, merged, conflicts resolved in text editors. The build step would be a very simple one: zip it.