Почему SQL-инъекции — это опасно?

Опасны - потому, что можно увести всю информацию из базы, ну или поломать её.
Скажем, в своём запросе подставьте $id = '1 OR true'
Защита - использование подготовленных выражений с плейсхолдерами.

Потому что можно сделать всё, на что имеет право текущий пользователь БД. Например:
1; DROP TABLE entries; --
превратится в запрос

SELECT * FROM entries WHERE id = 1; DROP TABLE entries; --

Также можно менять, добавлять, удалять записи, если есть на это права у пользователя, а обычно они есть. Если в БД есть возможность исполнения произвольных команд шелла, то можно и весь сервак похерить, ну или залить бекдор.

Что можно сделать вместо них?

google://sql prepared statement

Sql Injection это не вершина "опасности". По CVE score порядка 6-7.
Конечно же все зависит от конфигурации ПО, привилегий, обновлений и т.д.
Но стоит учесть тот факт, основная масса уязвимостей типа sql inj все же не union с error base, в 80% blind, что затруднит проведение эксплуатации, а если админ не будет спать в одном ботинке, то вовсе исключить, и исправить.
На получение структуры может уйти сутки двое. Не будем забывать еще и про WAF'ы, cloudflare, incapsula.

Хорошо, даже в случае спящего админа, допустим было получены записи с привилегированными запясями ресурса. Опять же вопрос к разработчику.. С md5,sha1 все ясно, а будь в blowfish хотябы 8мизначный пароль даже прописью, такой фактор обычно просто откладывается, ибо соблюдая методы минимальных парольных политик и шифрования может подарить безопасность довольно на долго (конечно не исключая плавновую смену паролей).

Предположим цель жизни было скомпрометировать сервис, и бедолага потратил порядка недели на раскрутку скули, обходы waf, и перебор хеша админа. Надеюсь же php настроен адекватно, и нету всяких привелегий у юзера mysql типа grand dba. Но и даже в таком случае можно уберечь конфеденциальные данные, даже при условии полного слива БД. Шифруйте важные данные, храня ключ не в бд. Такой best практайс встречаеться довольно редко, обычно на гигантских ресурсах, да еще с "вкусной" для злоумышленников сферой деятельности.
Да вприцнипе как пример подобного - стандарт хранения кредитных карт, если админ желает их логировать. braintree и куча других решений, да еще с мощным мониторингом, и крутыми фичами.

По сути довольно тривиальные шаги если позволяет специфика и нагрузки ресурса.

Но все же черт страшен как его малюют) У талантливого хакера будет на один вектор атаки всегда больше чем примененные средства защиты и фикса. Вообще не стоит забывать про еще несколько десятков куда посерьезней уязвимостей чем инъекции. И понимать что впорос только во времени. Рано или поздно появиться лазейка, не учтет админ, или очередная 0day.. И плакали все труды по обороне