Какие есть best practice для проектов под iPhone?
1) Уже обсуждали эту тему. Считаю, что полный отказ от стори боарда - глупостью. Стори боард существенно упрощает жизнь при проектировании интерфейсов, особенно когда Вы поддерживаете весь спектр девайсов (ретина/не ретина, ios 6/7, ipad/iphone/iphone 4"). 
К примеру, у вас есть кнопка, которая повторяется на куче экранов. Объявляете класс XXXButton, унаследованный от UIButton. В нем реализуете метод
-(void) setupButton, где тем же кодом прописываете все нужные изменения (шрифт, цвет, бэкграунд)
Далее переопределяете метод -(void)awakeFromNib или метод -(id)initWithCoder и вызываете в нем метод setupButton. 
В storyboarde добавляете обычную кнопку, но изменяете ей тип с UIButton на  XXXButton. Аналогично для других элементов UI. Получаете эдакий кривоватый аналог css+html. 
 Еще есть вариант выноса кнопки в отдельный xib и загрузки ее от туда. Но от этого может очень упасть производительность. 
Ну и да, иногда использование storyboardov действительно не оправдано...
Насчет таблицы, Apple любит многое переделывать в новых версиях прошивки, и те костыли, которыми Вы добивались нужной Вам верстки, могут внезапно сломаться. Все таки UITableView создана для списков.
2)stackoverflow.com/questions/5210535/passing-data-b... . Посмотртите ближе к концу ответ, отмеченный как правильный. NotificationCenter не самое лучшее решение. Более того, отсылая нотификацию нельзя быть уверенным, что ее вообще кто-то получит. Да мало ли там что на том конце провода, а если получатель ViewController еще не создан на момент отсылки нотификации?
3)- нормально ли, если связанные файлы как в java выделяются в отдельные каталоги. Или просто в x-code создавать виртуальные каталоги (refs), а реально все файлы складывать в одну папку.
Мне кажется лучше первый вариант. Потому как с проектом можно взаимодействовать не только через xcode- именование классов контроллеров. ContactsEditorViewController vs ContactsEditor. 
Лучше указывать что это конкретно ViewController, и да, не забывайте о префиксах. А еще очень рекомендую заглянуть на developer.apple.com. Там есть несколько статей о соглашениях по именованию классов, методов и т.п. Некоторые фичи без "правильных" имен могут сломаться (kvo , arc)
Да и всегда можно почитать рекомендации от того же гугла...
 4) Локализация
Это разные инструменты для разных целей. NSLocalizedString используется когда вам нужно перевести текст интерфейса. Storyboard localize - когда Вам нужно переделать интерфейс. Что бы Вам было понятней, представьте, что делается приложение ориентированное только на западного пользователя.  NSLocalizedString хватит с головой, была кнопка Home, стала Домой :). 
А вот если Вы захотите продавать приложение где-то на востоке, то тут окажется, что есть иероглифы, написание  справа на лево/сверху вниз. Да и вообще, не умеют они думать квадратно гнездовым способом, им подавай абсолютно другой интерфейс.
1 Нужно отказаться от storyboard, она была сделана для дизайнеров-программистов, имхо. Обычно, проект стилистически един, одинаковые поля ввода, одинаковые кнопки, отличаются только позиции, ну и всякие мелочи. В таких случаях создаю класс с статическими методами, которым передаешь CGRect и NSString, а они тебе кнопку или лабел например.
2 Нотификацию обычно используют, когда нужно оповестить несколько классов, например о загрузке данных. Для остального есть делегат и синглтон
3 Тут кому как больше нравиться, я раскладываю все по каталогам и создаю refs с иакими же именами.  Именую так - RootVC, UserView, UserItem
4 Отказавшись от сториборда, использую только NSLocalizedString