Because your own system offers you flexibility, specificity, smoother integration and more control over the output quality.

Flexibility

There are a lot of SMT solutions built around Moses, and all of them offer a certain degree of flexibility. Some allow you to change a whole list of parameters, while others just give you a field to enter a name for your translation engine. Generally speaking, the more flexibility a certain system offers, the less user-friendly, more complicated and error-prone that system becomes. The more complex systems can cause so much confusion or frustration that the productivity gain you want to get by using MT is completely lost. On the other hand the very generic ones won’t let you really improve the quality which causes frustration with your post-editors, which in turn is again detrimental for the rise in productivity you want to achieve.

When building your own system you can decide your own place on the complexity scale to better fit your needs, and those of your vendors and clients. You can implement the features you need and leave out the rest.
 

Flexibility

Specific for your costumers

Since you build a system that only needs to handle data you're familiar with, you can tailor it to fit that data. Instead of incorporating general rules to handle as much data as possible in the same way, you can implement specific sets of rules for specific customers and/or language combinations. This is much more difficult with an out-of-the box solution. This means however that it becomes necessary to adapt your specific rules to manage the constant changes to the data you have to translate.
 
You’ll need to find a balance between making a perfect set of rules that requires constant updates and relying on a more general, future-proof set of rules.
 

Customer Specific

Easy integration

Every LSP has its workflow and because of this some of the existing SMT solutions will not be taken into consideration from the outset. Some solutions are simply too hard to implement when a certain workflow has already been established. This is another problem you avoid when you design your own solution with your own workflow in mind.

Control over quality consistency

Every SMT solution I ever tried is built around Moses in some way or another. But some of them use their own data cleaning algorithms, tokenizers, xml-markup handlers... And when the software developers decide to adapt these, you as a user have little or no control over it. It might improve your results without any input from your side, but it might also mean that you're suddenly forced to make changes to your pre- or post-edit workflow. This is even more dangerous when you use MT for projects without human proofreading.
 
Even though building your own wrappers around the moses decoder might be resource consuming, the control you get in return might be worth it.
 

Quality Consistency

In conclusion

I guess we can say that an LSP can ask itself the question whether it wants to find the best fit among the many SMT solutions out there or whether it should try making its own. As it is very difficult to calculate the ROI in either case, it's not an easy decision to make. Nonetheless, depending on the resources and MT needs, it is a question worth asking.