Type theory and set theory are equivalent - they can express the same things. When you build software, you build upon types. But the software is fixed afterwards - you don’t change the types in the running system, they get even removed at compile time.

But what happens, if you want to build a general kind of software, where each customer can define their own types to customize it to their domain? You can not longer model the domain using programming language features like classes. Their model has to go somehow in the database.

It is possible to give users the ability model their own domain in your system - just look at programming languages, which are just software, too. They allow you to express your types and customize the software (the language in this case) for your domain. You store your domain model in a database (your file-system) where different tools then perform useful actions, like type checking, on them.

You could implement your own type system and store the information the database of your product. You could also implement tools on top of the types, that now live in that database, like type checking and check your data using it. But you can also use an ontology to do that, which does not depend on type theory, but set theory. The latter having the advantage to have a ton on existing work in that area.

So why using an ontology, and not a type-system living in a database? I don’t know. I guess a type-system driven approach would be easier for programmers to model and would integrate better with the rest of the software as both, the application-specific parts and domain-specific parts use type theory. Ontologies handle concepts and their relations and are built not for programmers, but to express data, so it may be a better fit to describe domain specific data. I have the feeling, that ontologies are built to express data and type-systems (at least the ones I know from programming) are built to express behavior.