Игорь Катков

Go не является языком совершенно другой парадигмы.
PHP является императивным.
Go является императивным.

Другая парадигма - это Erlang, Haskell, Nemerle.

Можешь изучать Python3.x , он как раз и лучше PHP, и хорош для изучения алгоритмов (приближен к псевдокоду).

Подумал вот о чем - стоит ли для этого выбирать GoLang?

Нет. Просто нет.
Ты можешь его изучить ради моды, но ты много будешь трахаться с самим языком, потому что это такой костюм от очень известных кутюрье, который они сшили только вчера, и из которого отовсюду торчат нитки (а иногда и целые тряпки), а некоторые карманы ещё будут перешивать с левой стороны на правую и с правой на левую.

Go не подходит на роль языка "совершенно другой парадигмы". Если хотите такой язык, гляньте в сторону Haskell, Clojure, Lisp.
Go подходит на роль языка с нестандартным ООП и нестандартной работой с многопоточностью.
Для общего развития точно стоит его посмотреть. Прежде всего, он более низкоуровневый, чем ПХП, соответственно, вы сможете увидеть и понять некоторые вещи, о которых раньше не задумывались, которые были незаметны пользователю в ПХП, но тем не менее важны для понимания. Плюс, поработаете с компилируемым языком.

Тоже на старте читал указанное. Но в итоге самыми полезными были Symfony Book, Symfony Cookbook и Symfony Best Practices на официальном сайте www.symfony.com
Бери гугл.транслейт и не спеша читай, без английского всё равно никуда.

Имеет смысл покрывать функциональными тестами, элементарно на статус 200 например.

Ведь тот же метод $em->persist(...); мы используем и для обновления записи.

Вообще-то нет. По умолчанию persist используется для того, что бы добавить сущность в UnitOfWork. Вызывая его доктрина начинает разбираться, нам надо просто замерджить сущность в текущий UoW или добавить ее в очередь на вставку.

Вызывать persist при обновлении не нужно вовсе, можно обойтись merge, и только если у нас используется политика отслеживания изменений deferred-explicit, но это нужно в очень редких случаях. Например когда в рамках одного запроса мы должны загрузить из базы сотню-другую сущностей а обновить одну. В этом плане данная политика отслеживания изменений сильно ускоряет работу UoW, так как мы явно указываем за какими сущностями нам следить (сложность алгоритма UoW - O(N), так что чем меньше N тем быстрее работает). Единственное НО - это сильно усложняет работу с entity manager (по хорошему em должен быть только в репозитории), и в принципе ломает красивую концепцию persistence ignorance, так что использовать ее нужно только тогда, когда есть проблемы с производительностью UoW.

через каждые 30 насколько изменится скорость переноса?

Да, это ускорит работу. Единственное что, если вы занимаетесь вставкой большого количества объектов, имеет смысл после каждого flush делать clear, отчищать unit-of-work, поскольку вставленные сущности будут крутиться в нем, и после каждого flush их количество будет увеличиваться и скорость будет падать.

Передать форму в шаблон:

'form' => $form->createView()

Рендер в twig:

{{ form_start(form) }}
{{ form_widget(form) }}
{{ form_end(form) }}

Это можно без dql сделать:

$options = $this->getDoctrine()
			->getRepository('AppBundle:Option')
			->createQueryBuilder('o')
			->select('o, v')
			->join('o.values', 'v')
			->getQuery()
			->getResult();

Для начала проверьте, что вы выполняете код в среде prod. Среда dev ест значительно больше ресурсов.
А дальше можно перейти на DQL без гидрации в объекты или вовсе на нативные запросы, которые ничего не возвращают в PHP, если сможете оформить запрос с такой логикой.

Если это разовая операция, то лучше не использовать Doctrine, а сделать все прямым запросом в базу данных. В крайнем случае, можно воспользоваться DBAL, но опять же обычным SQL-запросом.
Если же необходимо все сделать именно средствами Doctrine, то:

1. Оба репозитория записать в переменные и вынести их перед циклом
   
2. Проверить отношения между сущностями, учавствующими в этой операции. Скорее всего, вы не помечаете коллекции как LAZY или EXTRA_LAZY и из-за этого Doctrine тащит кучу ненужных сущностей, забивая память
   
3. Если п.2 не помог, то уменьшить кол-во итераций между очистками до 50 - 100
   
4. Если п.3 не помог, то увеличить кол-во памяти через ini_set('memory_limit', '512M');
   

Свойству $brand надо добавить @ORM\JoinColumn(name="brand_id", referencedColumnName="id")

$('li[data-category-parent-id=""]').append("<ul></ul>");

$("li").each(function(){
  var dts = this.dataset.categoryParentId;
  dts&&$("li[data-category-id="+dts+"] > ul").append(this);
});

P.s: Мне кажется, можно лучше...

UPD: Тест