OTP21がリリースされてから4ヶ月ほど経過しているので今更感がありますが, OTP21でerlang:get_stacktrace/0が廃止になりました.
try~catchで書かないといけない理由があったんだろうな. ぐらいの気持ちで当時リリースノートを流し見していたのですが, たまたま理由を目にする機会がありました.

Erlang Enhancement Proposal

EEPをご存知でしょうか. 今日まで私は知りませんでした.
珍しく見慣れないレポジトリをGithubにレコメンド？されたので見に行って知りました.

件の理由については, このプロポーザルに記載がありました.

EEP 47: Add syntax in try/catch to retrieve the stacktrace directly

The problem with erlang:get_stacktrace/0 is that it forces the stacktrace from the latest exception in a process to be retained until another exception occurs or the process terminates. The stacktrace often includes the arguments for the last function call, BIF call, or (in OTP 21) operator that failed. The arguments can be of any size.

つまるところ, 例外が発生するとプロセス上にstacktraceが保持され, 別の例外が発生するかプロセスが終了するまで消えないという理由で廃止になったようです.
あまりcatchした後プロセスを生かし続けることをしないので意識したことがありませんでしたが, 言われてみれば当然です.

In OTP 23 (or possibly OTP 22), erlang:get_stacktrace/0 will start returning []. Many programs that have not been updated will continue to work, except that if an exception is raised no stacktrace will be available to aid in debugging.

また, 現在はまだ保持していますが, OTP22もしくは23で保持しなくなり, APIは残したまま空配列を返すようになるようです.
パターンマッチがサポートされない理由についても記述があるので, 興味がある方は原文を読んでみてください.

EEP48, EEP49

• EEP 48: Documentation storage and format
• EEP 49: Value-Based Error Handling Mechanisms

まだ入っていない48と49についても面白そうな機能です. 49は仕様がどうなるか気になるところですが, erlanger待望の機能な気がします.
とはいえ古いバージョンにも対応させようとすると使えないので, 私が使うのは何年後でしょうか.