Закривати підключення не потрібно, воно буде закрите автоматично після завершення роботи скрипту.
Підключення до БД краще усього створити один раз, зберегти у контейнері, а потім витягувати його у тих класах, де воно потрібне. Такий контейнер називається Dependency Injection Container або Service Locator (реалізація однакова, термінологія залежить від методу використання). Є досить багато його реалізацій, зверніть увагу на ці:

http://pimple.sensiolabs.org
http://container.thephpleague.com/

Відкривати/закривати підключення кожен раз коли воно потрібне - дуже повільно, так робити не треба.

Так, щось на зразок такого. Але мушу зауважити, що це не дуже оптимально - інстанціювати моделі до того, як ви визначили маршрут. Навпаки, правильний хід подій - це спочатку визначити маршрут, потім маршрут визиває відповідний контроллер, а вже у контроллері ми визначаємо які моделі нам потрібні.

Ні, не краще. Сама ідея в тому, щоб ініціалізувати тільки ті класси, які потрібні для відображення сторінки і не більше.

Те, що у випадку зміни файлу/бібліотеки доведеться правити всі контроллери - це не дуже залежить від того, що і як буде ініціалізовано, це питання правильного контролю залежностей класів, і на цю тему можна писати цілу книгу. Основний принцип - Dependency Inversion, тобто, наведу простий приклад.

Це - пряма залежність. Клас UsersRepository залежить від класу ДБ. Якщо ми хочемо замінити клас ДБ на інший, який не має методу query - цьому коду хана, ми не знаємо, які методи старого класу де і яким чином використовуються. Щоб уникнути цієї проблеми, ми робимо наступну річ:

interface DBInterface
{
    function query();
}

class DB implements DBInterface
{
    function query()
    {
        return 'query result';
    }
}

class UsersRepository
{
    /**
     * @var DB
     */
    private $db;

    function __construct(DBInterface $db)
    {
        $this->db = $db;
    }

    function getAll()
    {
        return $this->db->query("SELECT * FROM `users`");
    }
}

Тепер клас UsersRepository не залежить напряму від класу DB, тепер обидва ці класи залежать від інтерфейсу. Цей принцип контроля залежностей називається Dependency Inversion, і він полягає в тому, що модулі вищого рівня (наприклад, UsersRepository) не повинні залежати від модулей нижчого рівня (реалізація підключення до БД), вони обидва повинні залежати від абстракції (тобто, інтерфейсу, який не містить в собі деталей реалізації).

Взагалі, це один з п'яти принципів SOLID. Цей набір - основа будь-якої правильної ОО-Архітектури, тому я б рекомендував ознайомитися, інакше продовжите писати процедурний гамнокод, але тепер з використанням класів

Я маю на увазі, що якщо в нас немає інтерфейсу, який показує, що за методи повинні бути у класа, ми не знаємо, які методи повинні бути у нового класу, і при заміні одного на інший ми будемо ловити несумісності по всьому коду. А так ми чітко бачимо, що в нього повинно бути, і навіть якщо є якісь нестиковки просто пишемо Адаптер, і заміна класу проходить швидко та безболісно.

В мене навіть є гарний приклад. Замінити в сервісі логування підключення з mysql-бази даних на mongoDB. Якщо логгер залежить напряму від методів PDO, mysqli чи враппера - маємо вагони геморрою. А якщо від інтерфейсу - задача спрощуєтся в рази.

Ну це вже питання реалізації, які не настільки важливі. Хоча я вже два роки перестав використовувати будь-що відмінне від PDO та prepared statements.