I think this philosophy might be oversimplified. Tana has basically two primitives (bullets and supertags) and manages to be devastatingly complex to use to the point you have to watch hours of tutorials to do very simple things. Conversely Google Maps has a lot of “primitives” but the UX is fairly tight for 90% of use cases.
It applies more to design software, where a user is creating durable things and needs to understand those things themselves. Google Maps is more of an agent: It's responsible for understanding its own complexity and answering your queries.
My point is that, sometimes, going for the lowest common denominator or "noun" and declaring it to be your primitive (focusing on minimalism), is a worse approach than picking a larger set of primitives that suits your design. Take Hangul (한글) for example, where the primitives are designed to serve a goal, and there's no effort to "ruthlessly" minimize the number of primitives, and this is something you can learn to read in 10 minutes, or at least in a day. Whereas if you go over to something like Chinese, your numbers 1, 2, and 3 look nice thanks to your stroke primitive, but your needs quickly overwhelm your design and you end up with something quite unwieldy compared to if you had picked a more complex set of primitives — you will never learn to read all Chinese in your whole life even as a native speaker. It's a counter-intuitive design lesson.
Doesn't Jira only have one primitive: the ticket.
Everything else just augments it.
You could say that these augmentations are separate primitives, but then the same would apply to all tools in the other cited examples like Photoshop too
Tana is basically a programming environment disguised as a text editor (in this way, it follows in the grand tradition of emacs you could say)
Vaguely feels like "Atomic Design" but applied to engineering.