Когда использовать LINQ to SQL вместо хранимых процедур для запросов? А когда не надо?

Когда тебе не нужны эти хранимые процедуры.

1)Ну то, что с помощью LINQ можно делать запросы к коллекциям это я уже понял, и понял насколько это удобно.
2)Я так понимаю, если нужно работать с каким-то набором данных из базы и делать к нему много мелких (ну в принципе и не только уж прям мелких) запросов, то удобней будет делать запросы на клиенте с помощью LINQ, чем замусоривать кучей хранимок сторону сервера. Правильно?
3)Правильно ли я понимаю, что LINQ to SQL это и есть O/R Mapper фактически?
4)Как вы считаете, целесообразно ли полностью перевести под LINQ to SQL приложение, которое является, можно сказать, оболочкой над базой, в том смысле, что с ног до головы сплошная работа с базой (сейчас у меня куча хранимок для запросов [список даже листать не удобно, такой он большой]).

4) нет

В некоторых местах, там где нужна производительность, выборка большая, оставляем хранимки. Что теперь по поводу 4-го вопроса? (По поводу полного перевода под LINQ to SQL я погорячился, конечно).

Да не трогай ты то, что и так работает. Если интерфейс плохой , оберни его в хорошую оболочку , но трогать работающий код смысла я не вижу.

Не трогай то, что хорошо лежит. Если лежит какашка, заверни в красивую бумажку и пусть дальше лежит   

а если немного изменится структура базы данных? Переписать х.процедуры это одно, а перекомпилировать приложение и переставить это другое