Very old code, hard to say what the thinking was at the time. That is why we are doing an audit looking for any unneeded regexes, or regexes that are susceptible to backtracking

Most likely answer: The built-in trim isn't Unicode aware or has buggy behavior when dealing with Unicode.

.NET builtin trim lets you specify which 'char' values to trim [1]. .NET is notoriously tied to UTF-16 (a char is 16 bit), and you have to handle surrogate pairs very carefully, but I can't really imagine that being any better with the built-in System.Text.RegularExpressions.Regex

1: https://msdn.microsoft.com/en-us/library/d4tt83f9(v=vs.110)....

Assuming they're still using ASP.net 4+, it is very unicode aware/safe. I don't know why a developer would reinvent Trim() but I do know it isn't a .Net limitation.

This code was written 5 years ago, and back then the trim function was different.

My guess is developer cleverness. As the article mentions they ended up with a less clever solution.

I like the trim() functions that accept a list (of some form) for 'characters to remove'. It is far more deterministic (better worse case outcome) to follow this approach than it is to run a regexp.