I had a similar issue not that long ago: the culprit seems to be some app ART cannot compile for some reason. As you successfully applied my solution and confirmed, let me sum up the facts from the comments in an answer:
1. figure which app is the culprit.
On each of those crashes, the Android system sets a "tombstone" on the "grave" of the dying process – something known on Unix/Linux systems as Core Dump. Those core dumps are placed into /data/tombstones, with at maximum 10 files kept (after that, the oldest one will be overwritten on the next occasion). So we need to look to those tombstones to see whats written on them. As you have a custom recovery which offers adb access, the easiest way is:
adb pull /data/tombstones tombstones (will copy the entire directory to your computer)
- use a viewer/editor of your choice (best one you are familiar with) to open and investigate each of the tombstones, starting with the newest and walking back.
- look into the "stack trace" to see if an app (or it's path in
/data/data) is mentioned there. If so, note it. If it's the same app in the next tombstone and the one after, you can be pretty sure this is the case we're describing here.
2. put the "obstacle" out of ART's way
Having identified the app, we need to remove it so art doesn't get stuck with it. For this, again we need adb shell with its root prompt – and the directory name from our tombstones:
rm -rf /data/data/<whateveritwas>
Note this removes all the data of the app as well – so having a backup in advance might be a good idea (in the current state: either adb pull the directory, or do a nandroid backup you can analyze later).
That done, reboot. Now "optimizing apps" should finish successfully.
Alternatives to the command-line approach
Some custom recoveries ship with an integrated file manager, usually called "Aroma". Above steps could also be perfomed with that:
- navigate to
/data/tombstones
- view the tombstones
- navigate to
/data/data and remove the offender