比較表

用途	Ruby/Rails	Elixir/Phoenix	評価
スキーマ管理＆マイグレーション	ridgepole	ecto_migrate	-
認証	devise	ueberauth	△
認可	cancancan	guardian	○
ソーシャルログイン	omniauth	ueberauth_*	○
REST API	grape	maru	○
管理画面	activeadmin	ex_admin	△
画像アップロード	carrierwave	arc	△
AWS連携	aws-sdk-rails	aws-elixir/ex_aws/erlcloud	○
i18n	i18n	gettext/linguist	○
(Modelの)多国語対応	globalize	-	-
設定値管理	rails_config	-	△
ジョブ管理	whenever	quantum-elixir	-
ElasticSearch連携	elasticsearch-rails	tirexs	△
memcached連携	dalli	plug-session-memcached	△

備考

ecto_migrate

ridgepoleと同様に、マイグレーションファイルを生成する必要がないのでその点は便利です。(自動的にALTER文を生成してくれる)
フィールドの型(string等)を変更しないと、フィールドのサイズ変更が行えないようです。(ここがかなり不便)
iexから実行する場合(EctoItを使用する場合)、MySQLではrootユーザのパスワードを空にしておく必要があります。
現時点の最新バージョン(0.6.3)がectoのバージョン1.0.xに依存しています(ectoの最新バージョンは1.1.3なので古いectoを使用する必要があります。ここもちょっと問題)
結論として、現時点ではectoの通常のmigrate機能を使用しておいた方が良いと思われます。

(2016/02/23追記)
ectoの通常のmigrate機能を使う場合、スキーマ変更時にマイグレーションファイルを毎回記述しなければならないという問題以外に、Railsのdb/schema.rbに該当するような、現在のスキーマ構造を簡単に確認出来るファイルを生成してくれないという問題もあります。

これらのことを考慮すると、スキーマ管理とマイグレーションに関してのみ、Rails(ridgepole)で対応するというハイブリッドな手法も検討する価値があるかもしれません。

ueberauth

deviseと比較すると機能は少ないです。(パスワード変更時の確認メール送信等の機能が必要な場合は自分達で作りこむ必要があります)

guardian

JWTが使用されています。APIの場合はAuthorizationヘッダーで、通常のHTMLビューの場合はCookieでJWTをやりとりする方式になる感じでしょうか。
guardiandbを使用することで、サーバー側の操作で特定ユーザーをログアウト状態にすることは可能なようです。

ueberauth_*

ueberauth_facebookやueberauth_twitter等の、ueberauthの派生パッケージでソーシャルログインが可能です。facebook/twitter/google/github等のOAuth認証に対応しています。

maru

elixirのREST API用パッケージとしては最もダウンロード数が多いようです。
grapeを元にして作られています。
viewを使う必要がないようなので、普通にcontrollerでAPIを定義するよりは使うファイルが減りそうな印象です。
Railsのjbuilderのような、JSONテンプレート用のパッケージはまだ存在しないようです。

ex_admin

activeadminとほぼ同様なUIが実現されています。
チュートリアルを試してみたところでは、ほぼactiveadminと同様な機能が実現されているような印象です。
上記チュートリアルでは省略されていましたが、ueberauthとの連携も可能です。(ただしguardianとの連携は難しそうです)

(2016/03/20追記)
画像やファイルのアップロード機能が追加されました。(ただしarc_ectoを使用しているため、Insert処理の場合には画像をアップロードすることは出来ません)

arc

carrierwaveと同様に画像アップロード時のリサイズも可能なようですが、imagemagickのオプションをそのまま指定する必要があります。
S3へのアップロードも可能なようです。(後述するex_awsに依存しています)
ectoと連携可能なようです。

aws-elixir/ex_aws/erlcloud

aws-elixirは、AWS SDK for GOのAPI定義ファイル(JSONで記述されている)からelixir用に生成されたコード群のようです。(なぜかEC2/S3用のAPIが存在しません)
ex_awsは現時点でDynamo/Kinesis/Lambda/SQS/S3のみに対応。(S3を操作したい場合はこれを使うような感じなのかなと)
erlcloudはerlang用のAWS SDKです。(基本的にはこれを使えば大体なんでも出来る？)

gettext/linguist

Phoenixではgettextが推奨されているようですが、個人的にはpoファイルよりもymlファイルの方が管理しやすいような・・・。
linguistは、Railsのi18nのようにロケールを自動判定するようなことは出来ないようですが、I18n.t(locale, "flash.notice.hello")のような、Railsでお馴染みの構文で使用可能です。ただしPhoenixではlinguistの使用は推奨されていないようです。

(Modelの)多国語対応

Railsのglobalizeのような便利パッケージは存在しないので、Modelのフィールドも多国語対応したい場合は、それ用の機能を一から作りこむ必要があるようです。

設定値管理

config.exsファイル等に定義して、Application.get_env/3関数でアクセスするのがスタンダードのようです。(rails_configではymlで階層構造を定義してSettings.foo.barのように簡潔な構文でアクセス出来たのですが・・・)

quantum-elixir

Rails + whenever + capistranoのように、cronが動作するインスタンスをデプロイ時に動的に決定するようなことは出来ないようです。
ジョブ管理に関してはPhoenixと切り離した方がよいかもしれないなあという印象です。

tirexs

elasticsearch-railsのように、Modelと簡単に連携するようなことは出来ないようですが、ElasticSearchを操作する上で最低限の機能は提供されているようです。

plug-session-memcached

dalliと異なり、セッションストレージ専用のようですが、その用途のみに割り切るなら有用と思われます。

最後に

誤りのご指摘や、「こっちのパッケージの方が便利だよ」というような情報を頂けますと大変ありがたいです。よろしくお願い申し上げますm(__)m

RailsとPhoenixのパッケージ比較表

比較表

備考