A few characteristics of both protocols might help you choosing one to work with.
CMIS
Started as a mean to federate content across different (document) content repositories, its core business is letting diverse content repositories talk to each other over a web interface (REST / WS). While the latest edition of the protocol improved browser operations with content through the JSON based browser binding, CMIS often shows up as a bit of a chatty protocol, not always shining for content delivery.
PROS: standard, supported by a multitude of vendors, supports a slightly richer data model (Renditions, Policies)
CONS: chatty, lots of XML parsing if using the AtomPub or WS bindings, can't create custom service APIs
Sling
I am no expert on this, but as far as I gathered it's a lightweight, extensible HTTP layer on top of JCR. Data processing logic is tied to the content you request via HTTP as Components, giving you the ability to process and eventually optimize content before delivery.
PROS: adds a data processing layer on top of content retrieval, works on plain HTTP without complex payloads to describe each action
CONS: non standard, can't easily swap content repository