The way I see it, you both have the advantage, and you are at a "disadvantage" (sic).
The advantage is that you have a system that you feel comfortable with, and which works for you. You are happy that it confirms the validity of your product, and you would probably find no business value in attempting to change all of your tests for something that uses a different framework. If you can refactor your code, and your tests pick up the changes - or better yet, if you can modify your tests and your existing code fails the tests until it is refactored, then you have all of your bases covered. However...
One of the advantages of having a well designed unit testing API is that there is a lot of native support in most modern IDE's. This won't affect the hard-core VI and emacs users out there who sneer at the Visual Studio users out there, but for those of use who make use of a good IDE, you have the ability to debug your tests and execute them within the IDE itself. This is good, however there is an even greater advantage depending on the framework you use, and that is in the language used to test your code.
When I say language, I'm not talking about a programming language, but instead I am talking about a rich set words wrapped up in a fluent syntax that makes test code read like a story. In particular, I have become an advocate for the use of BDD frameworks. My personal favorite DotNet BDD API is StoryQ, but there are several others with the same basic purpose, which is to take a concept out of a requirements document, and write it in code in a similar way to how it is written in the spec. The really good APIs however go even further, by intercepting every individual statement within a test and indicating whether that statement executed successfully, or failed. This is incredibly useful, as you get to see the entire test executed without returning early, which means your debugging efforts become incredibly efficient as you only need to focus your attention on the parts of the test that failed, without needing to decode the entire call sequence. The other nice thing is that the test output shows you all of this information, both in the console and also with some APIs in a nicely formatted report that you can give to management if they are interested in that sort of thing.
As an example of what I am talking about, compare the following:
Assert(variable_A == expected_value_1); // if this fails...
Assert(variable_B == expected_value_2); // ...this will not execute
Assert(variable_C == expected_value_3); // ...and nor will this!
Using a fluent BDD API:
(Imagine that the italicized bits are basically method pointers)
.Given(*AConfiguration*) // each method
.When(*MyMethodToTestIsCalledWith*, variable_A, variable_B, variable_C) // in the
.Then(*ExpectVariableAEquals*, expected_value_1) // Scenario will
.And(*ExpectVariableBEquals*, expected_value_2) // indicate if it has
.And(*ExpectVariableCEquals*, expected_value_3) // passed or failed execution.
Now granted the BDD syntax is longer, and wordier, and these examples are terribly contrived, however for very complex testing situations where a lot of things are changing in a system as a result of a given system behaviour, the BDD syntax offers you a clear description about what your are testing, and how your test configuration has been defined, and you can show this code to a non-programmer and they will instantly understand what is going on. In addition, if "variable_A" fails the test in both cases, the Asserts example would not execute past the first assert until you had fixed the problem, while the BDD API would execute every method called in the chain, in turn, and indicate which individual parts of the statement were in error.
Personally I find this approach works much better than the more traditional xUnit frameworks do in the sense that the language of testing is the same language as your customers will speak of their logical requirements. Even so, I have managed to use xUnit frameworks in a similar style without needing to invent a complete testing API to support my efforts, and while the asserts will still effectively short-circuit themselves, they read more cleanly. For instance:
const int theExpectedValue = someValue;
var theActualValue = WhenIExecuteMyMethodToTest();
Assert.That(theActualValue, Is.EqualTo(theExpectedValue)); // nice, but it's not BDD
If you do decide to explore using a unit testing API, my advice is to experiment with a large number of different APIs for a little while, and to keep and open mind about your approach. While I personally advocate for BDD, your own business needs may require something different for your team's circumstances. The key however is to avoid second-guessing your existing system. You can always support your existing tests with a few tests using another API if needed, but I certainly wouldn't recommend a huge test rewrite just to make everything the same. As legacy code falls out of use, you can easily replace it and its tests with new code, and tests using an alternative API, and this without needing to invest in a major effort that won't necessarily give you any real business value. As for using a unit testing API, if the syntax allows a nice natural language to be used, and if even better, the framework allows your coding/debugging efforts to become more efficient, then you probably can make a good business case for using a suitable unit testing API.