Parcelable は Android 固有のシリアライズの仕組みで、Java でも Kotlin でも使えますが、実際にシリアライズ・デシリアライズの処理を自分で書く必要があり、面倒かつバグの素でした。@Parcelize は Kotlin で Parcelable を簡単に実装するための仕組みになります。
ちなみに、Java がもともと持っているシリアライズの仕組みとして Serializable というものもあり、Android でも使えますが、Parcelable と比べると高機能だけど非効率なので、Android では Parcelable の方が推奨されています。(とはいえ、Java では Parcelable は面倒なので、あえて Serializable を使うことも少なくなかったり…。)
Parcelable の弱点は、クラスの内容の変更 (プロパティが増えたり減ったり型や順番が変わったり) があるとデータの互換性が失われてしまうことです。(あまり詳しくありませんが、Serializable は多少の変更には対応できたはず…。)
Android で Parcelable を使う場面ですが、主に Activity の状態を保存したり、Activity や Fragment (やサービスなど) の間で情報をやり取りするために使います。例えば、ListActivity から DetailActivity に Person オブジェクトの情報を渡す場合、id や name などを別々に渡すより、Person オブジェクトのデータを丸ごと渡したいですよね。
ここでおそらく疑問なのが、なぜ Person オブジェクトをそのまま渡さないのかってことだと思います。わざわざ渡す側で Person オブジェクトの中身を取り出して小包に詰めて、受け取った側でそれを元にオブジェクトを作り直してるわけですからね。(実際、iOS ではそんな面倒くさいことはしてませんし…。)
これには Android の設計思想が関わってきます。Android では、一つのアプリに属する複数の Activity を別々のプロセスで動かしたり、あるいは別のアプリの Activity を呼び出すことができるように設計されています。また、画面を回転しただけで Activity が破棄されて作り直されたり、メモリが足りなくなった時にバックグラウンドのアプリを終了させてフォアグラウンドに戻った時には元の状態を保ったまま起動し直すなどということも起こります。これらが円滑に行われるためには、いろんな情報を簡単に一時保存・復元するための仕組みが必要で、Parcelable はそのために使われています。
というように、Android 開発では Activity や Fragment をなるべく独立性を保って作るのが良いとされています。(とはいえやりすぎ感もあり、それを補うために ViewModel などが作られたわけですが…。)