This is a case of performing three analyses, and looking at partial mitigations.

(1) You have a vulnerability in the package, but does it constitute a vulnerability in the system?

Versions of Log4J have vulnerabilities when used in specific ways. Do you know whether the vulnerability is detected by simply seeing the version has a CVE, or is the vulnerability exploitable in your use case? Has a penetration test been done that validates the Log4J vulnerability causes SharePoint 2013 to be vulnerable in some way?

(2) If you have a vulnerability in the system, does it constitute a risk?

This is a function of the threat that may exist. If the server is only accessible to internal users then you want to consider at least these two questions:
- Do you have an insider threat which you need to protect against?
- Could the system vulnerability realistically be exploited by an external attacker using a XSS vulnerability or other network-based attack?

(3) What is the value at risk from the vulnerability compared to the value at risk from the functionality supported?

Let's say that you quantify a potential loss (direct losses, reputation, penalties) of a million dollars from the vulnerability being exploited. If the value of the functionality exceeds this, then economically you should retain the service, potentially with mitigations in place.

Mitigations

It may be that the vulnerability can be mitigated by disabling specific features of Log4J. For example, if you do not require JNDI support (quite likely you do not) then you can delete specific classes from the .JAR file and not break the service, but prevent JNDI-based attacks.

Alternatively, can you put a WAF on the server to filter attacks?