Potentially, if there is a need for the description logic supported by OWL. Some of the logic would be pushed from the application into the data layer, e.g. as a replacement for something like Prolog in the app. If you're dealing with a database and not a "knowledge base" of facts, then it's probably not for you. If you need a graph database, consider regular graph databases instead.
I have never seen a case where a triple store was used because it was necessary to achieve an outcome. It was always part of the premise, to show that a certain task can be achieved using triple stores. The "semantic" label is also problematic, some people think that "semantic" technology is magic and will somehow help them solve their problems.
My experience with semantic technology is from University and a commercial project. An architect who didn't talk to the engineering team decided that "semantic" technology should be used. The project was a catastrophe, we spent most of the time trying to get the technology to work for the simplest things. The situation improved when we started working around the semantic stuff, using a relational DB internally allowed us to improve performance by a few orders of magnitude.
Because all data is stored as triples of subject, predicate and object, the indexing options for improving query performance are limited compared to relational databases. While it's possible to change the graph structure to speed things up, the structure is usually chosen for semantics and defined in an ontology. A change in the structure is also a change of the semantics of the graph.
Given an undocumented triple store, it's quite difficult to figure out the graph structure stored inside. In a relational database you can just run the equivalent of "SHOW TABLES" and go from there. In the semantic world, you need a manual for the ontologies used. It's sad because the whole point of "semantic" technology was to attach meaning to data.
Triple stores also receive way less attention than databases like Postgres or MariaDB and I'd rather use something proven in production scenarios.