Because in certain tableView delegate methods, in my case the - (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath method was being called out of order. 

As a result (in this order), 
1.) The object would be deleted from the persistent store, 
2.) The object would be removed from the array which would… 
3.) reload the tableview BEFORE
4.) The simple table view's sections and rows were reconfigured to handle the change. Even though it was asked to do so in the line above, the amount of rows in the datasource were still always higher than it should have been. Not sure why given it was set right above but it would always ask if it could edit the row that was just deleted. This would cause the 
5.) canEditRowAtIndexPath method to ask about the row that doesn't exist anymore. This lead to
 6.) Crash.

Essentially, the correct way to delete a row is in lines 228-233. You begin updates, you delete rows (or if it's the last row in the section, the section) and the end update. TableView knows that there is one less row and acts accordingly.

The alternative was a couple if-statements in the canEditRowAtIndexPath method to make sure it wasn't going to ask for a cell that was not existent. That seemed like an awkward work around for having the convenience of putting reloadData in the setter of the Array.