Не используйте .Remove(0, sb.Length), используйте .Clear(). Его легче читать, и если Remove не был оптимизирован для этого особого варианта использования, Clear тоже будет быстрее.
Или просто выделите новый StringBuilder. Сам StringBuilder легок, поэтому я не думаю, что использовать новый будет дорого.
Я обычно не стал бы выделять Clear() и выделять новый StringBuilder, основываясь на преимуществах производительности одного, но на которых создается лучший читаемый код. И это зависит от вашего варианта использования. Не оптимизируйте микро, если только ваш профилировщик не показал, что это необходимо.
По моему опыту, вы выделяете новый StringBuilder в начале какого-либо метода и вызываете ToString только при создании возвращаемого значения функции. В этом случае глупо усложнять интерфейс функции только для повторного использования StringBuilder.
И я думаю, что когда вы вызываете ToString(), StringBuilder выдает свой внутренний, поэтому внутренний буфер становится неизменным, и StringBuilder должен в любом случае выделять новый для следующего изменения.
Одна микрооптимизация, которая может быть полезной, - это передача емкости конструктору StringBuilder, если вы точно знаете (или хотя бы нижнюю границу), как долго будет длиться результат. Тогда не нужно увеличивать массив в несколько шагов. Например, если вы знаете, что вывод будет не менее 10000 символов, вы можете инициализировать компоновщик до 10000.