便利なところ

矢印や記号、コメントなどシーケンスを描くのに必要なものは一通り揃っていて、記載方法も矢印は”->”で表すなど直感的で分かりやすいです。
以前は、Excelでシーケンスを作成していたのですが、記号どうしの重なりや間隔などを逐一手動で調整しなければならなかったのですが、PlantUMLは、ツール側が自動で調整してくれるため、かなり効率よく描けます。
テキストでシーケンスを描くので、コーディングしている時と同じような感覚で書けるので、図を描くよりコーディングイメージが沸くような気がします。
例えば、とある処理をシーケンス図として記載すると下記のようになります。

@startuml
hide footbox
 
title そんな、ひどい…
 
actor 姫 
control 会話ウィンドウ
control 効果音
 
[->> 姫 : 話しかける
activate 姫
 
    姫 -> 姫 : 確認処理
    activate 姫
        loop 無限ループ
            姫 -> 会話ウィンドウ : はい/いいえ表示\n「姫のことを\nおもってくださいますか？」
            activate 会話ウィンドウ
 
                ref over 会話ウィンドウ : はい/いいえ表示処理
 
                break "はい"を選択
                    姫 <-- 会話ウィンドウ : はい
                end
                
            姫 <-- 会話ウィンドウ : いいえ
            deactivate 会話ウィンドウ
 
            |||
 
            姫 -> 会話ウィンドウ : 表示\n「そんな、ひどい…」
            activate 会話ウィンドウ
            姫 <-- 会話ウィンドウ
            deactivate 会話ウィンドウ
 
            note right of 姫 : "いいえ"を選ぶ限り、無限ループ
 
        end
    姫 <-- 姫
    deactivate 姫
 
    |||
 
    姫 ->効果音 : アイテム取得音
    activate 効果音
    姫 <-- 効果音
    deactivate 効果音
 
    姫 -> 会話ウィンドウ : 表示\n「うれしゅうございます。ぽっ」
    activate 会話ウィンドウ
    姫 <-- 会話ウィンドウ
    deactivate 会話ウィンドウ
 
[<<-- 姫
deactivate 姫
 
@enduml

Excelで記載するとloopやbreakなどの枠位置や、オブジェクト間の幅など手動で調整しなければいけないところ、特に気にすることなく記述できます。

困ったところ

全体的に自動で描いてくれる利点が、融通の利かない箇所となってしまっている感があります。
例えば、ダメな点として、上記図で表すと、

ライフラインの実行状態 や 応答メッセージ は記載しないと表示されないところ や
書き方によっては、ライフラインの実行状態と普通のメッセージがあり得ないような表示になってしまったりなど、自動で描いてくれるのが逆に仇となっています。
また、UMLに準拠した図なら問題ないのですが、お客様向けに分かりやすくしようするなど、準拠から外れたものは描けないのが残念な点でしょうか。

度重なる継承や、部品化により複雑になっていたクラス間の関係性を、新規参画者にもわかりやすいように整理しようと思い、クラス図を作成しました。

便利なところ

全体の構成を考えなくとも、クラスと関係さえ記載すれば、少ない時間で、綺麗な図が作成できるところ。
例えば、以下の様にクラスだけ列挙します。

title クラスチェンジ表
'武闘家
class "MartialArtistClass\n武闘家" as MartialArtist {
}
'戦士
class "WarriorClass\n戦士" as Warrior{
}
'バトルマスタ
class "BattleMasterClass\nバトルマスター" as BattleMaster {
}
'僧侶
class "MonkClass\n僧侶" as Monk{
}
'魔法使い
class "WizardClass\n魔法使い" as Wizard{
}
'賢者
class "SageClass\n賢者" as Sage{
}
'パラディン
class "PaladinClass\nパラディン" as Paladin{
}
'勇者
class "BraveClass\n勇者" as Brave{
}
'村の少年
interface "VillageBoy\n村の少年" as VillageBoy{
}

すると　関係性のないクラスが列挙されます。
(ここでは改行コード'\n'を入れることによって、ER図の様に物理名、論理名をクラス図で表現しています。また、別名をつけているのは、関係性を表すときに簡素に記載する為です。)
次に、以下の様にクラス同士の関係性を追記します。

'村の少年の可能性
VillageBoy <|..d. Wizard :就職
VillageBoy<|..d. Monk :就職
VillageBoy <|..d. MartialArtist :就職
VillageBoy<|..d. Warrior :就職
'賢者のクラスチェンジ条件
Wizard <--- Sage :派生
Monk<--- Sage :派生
'パラディンのクラスチェンジ条件
Monk <--- Paladin :派生
MartialArtist<--- Paladin :派生
'バトルマスターのクラスチェンジ条件
MartialArtist <--- BattleMaster :派生
Warrior<--- BattleMaster :派生
'勇者のクラスチェンジ条件
Sage <--- Brave :派生
BattleMaster<--- Brave :派生

おお！なんとなくクラス図っぽくなりました！次にクラスの種別ごとに'package'でグループを作り、色付をします。

package 基本職{
'武闘家
class "MartialArtistClass\n武闘家" as MartialArtist #DEDFEF{
}
'戦士
class "WarriorClass\n戦士" as Warrior #DEDFEF{
}
}
package 上級職{
'バトルマスタ
class "BattleMasterClass\nバトルマスター" as BattleMaster #FCF1D3{
}
}
package 基本職{
'僧侶
class "MonkClass\n僧侶" as Monk #EEF5D3{
}
'魔法使い
class "WizardClass\n魔法使い" as Wizard #EEF5D3{
}
}
package 上級職{
'賢者
class "SageClass\n賢者" as Sage #FCF1D3{
}
'パラディン
class "PaladinClass\nパラディン" as Paladin #FCF1D3{
}
}
package 伝説の職業{
'勇者
class "BraveClass\n勇者" as Brave #F3D1E5{
}
}
'村の少年
interface "VillageBoy\n村の少年" as VillageBoy{
}

オブジェクトとオブジェクトの距離感もいい感じで、素早く書くことが出来ました。

困ったところ

PlantUMLが勝手にクラスを並び替えてくれるので「このクラスの隣はこのクラスが美しい！！」みたいなSEとしてのこだわりは、位置を厳密に指定しないとPlantUMLさんには関係ないので、無視されてしまいます。
また、全体のバランス感覚には弱く、「もっとこのオブジェクトは右の方がいいのだけど・・」と思うことがままあります。
先ほどのクラスチェンジ表で言うと・・・

<中略>
package 基本職{
'武闘家
class "MartialArtistClass\n武闘家" as MartialArtist #DEDFEF{
}
'戦士
class "WarriorClass\n戦士" as Warrior #DEDFEF{
}
}

オブジェクトの左右が入れ替わる現象については、線が重ならないようにPlantUMLが努力してくれた結果なので、メリットかも知れません。
RGBを指定してクラスに色を付けたり、'package'を使いクラスの纏まりを作ることで、見やすい図は作れるかと思います。
何よりも作成速度が速いので、「どうしても美しさを追い求めたい・・」という場合以外はお勧めです。

複雑な処理周りを簡易的なコンポーネント図にすることで相関関係を把握するために作成しました。

便利なところ

Excelなどで作成する時のようなオブジェクト一つ一つを動かす必要がなく自動的に図を作成してくれました。そのため作成時にオブジェクト操作に時間を割かずに狙った作業に注力できました。コードでの作成となるため処理の関係性が把握しやすかったです。
例としてプラモデルをコンポーネント図として下記に記載します。

@startuml
title "プラモデル"
node "部品Aグループ"{
component "部品A-1" as PartA1
component "部品A-2" as PartA2
component "部品A-3" as PartA3
}
node "部品Bグループ"{
component "部品B-1" as PartB1
component "部品B-2" as PartB2
component "部品B-3" as PartB3
component "部品B-4" as PartB4
component "部品B-5" as PartB5
component "部品B-6" as PartB6
component "部品B-7" as PartB7
}
node "つなぎ部品Cグループ"{
interface "つなぎ部品C-1" as PartC1
interface "つなぎ部品C-2" as PartC2
}
PartA1 --> PartA2
PartA1 --> PartA3
PartA1 --> PartB1
PartA1 --> PartC2
PartA2 --> PartB2
PartA2 --> PartB3
PartA3 --> PartB4
PartA3 --> PartC1
PartC1 --> PartB5
PartC2 --> PartB6
PartC2 --> PartB7
@enduml

部品Bが多く、部品Aやつなぎ部品Cとの関係性を把握するのが難しかったですが、明確になりました。

困ったところ

ただ、図が狙った通りに作成されるわけではないので、結局見た目の調整する時間が割くことになりました。それでも、今回の複雑な処理を図にする場合ではExcelでやるよりも時間は短縮されたと思います。
実は関係性を書き出した後はもっと見づらいものでした…

プレビューを見ながらコードを修正しました。

PartA1 -> PartA2
PartA1 -> PartA3
PartA1 -> PartB1
PartA1 -> PartC2
PartA2 -> PartB2
PartA2 -> PartB3
PartA3 -> PartB4
PartA3 -> PartC1
PartC1 -> PartB5
PartC2 -> PartB6
PartC2 -> PartB7

修正後

PartA1 --> PartA2
PartA1 --> PartA3
PartA1 --> PartB1
PartA1 --> PartC2
PartA2 --> PartB2
PartA2 --> PartB3
PartA3 --> PartB4
PartA3 --> PartC1
PartC1 --> PartB5
PartC2 --> PartB6
PartC2 --> PartB7

便利なところ

テキストベースなので、TFVCやGitで管理した時に、差分が見やすいですし、複数人で同時に更新できる処も魅力です。
画像だとどこが変わったのか、目で確認しないといけません。Excelの場合は同時編集の有無や競合にも注意を払う必要があります。
素早く、統一された書式で描けるので、複数人で描いても見た目にバラつきが少ないです。そのぶん記載内容に集中できるところは嬉しいですね。

困ったところ

閲覧するにはGraphviz必須ですので、Graphvizが無い相手に渡す時（例：納品時）は図に変換する事でしょうか。
ソースコードからクラス図を起こす等、ソース連携したいなら、他ツール(AmaterasUML、astah)のほうが良さそうです。

これで彼女ができる！ITディレクターの課題分析術
要件定義。それが一番大事。