Having used both, Enterprise Architect might be more formally maintainable, but from a CBA (can't be arsed) perspective, PlantUML blows it out of the water. If you use imports in PlantUML, you can define your "objects" or even common actors or events in their own separate pumls, anyway.

Just my 100% subjective read.

from what I've seen of an architect working in EA on video call, EA allows to more flexibly define objects - and doesn't put any preconceptions on their use. With PlantUML I'd beware that my common definitions have assumptions about being used in specific contexts.

But it's something to test out! :)

Definitely worth checking out :). At some point, they bit the bullet and included a programming language inside[0].

https://plantuml.com/preprocessing

It's enough to make it easy to organize common chart elements into libraries, and even create some DSL here and there - the latter being helpful if you're using PlantUML for note taking or in lieu of doodling :).

For instance, I got a very good mileage out of "trivial" definitions like:

  !procedure call($source, $target, $call)
  $source -> $target: $call
  activate $target
  !endprocedure

Forming a mini-DSL that let me turn notes like:

  call("Someone", "SomeoneElse", "FooBar()")
  asynccall("SomeoneElse", "SomeService", "Run(a=42)")

Into a rather large sequence diagram that's also readable as text, and possible to auto-generate to some extent.

--

[0] - Which looks like a spawn of an unholy marriage between PHP and C preprocessor... but hey, it's a programming language.