It comes down to one keystroke
Keeping a history of what you copy needs no such permission, and neither does putting an item back on the clipboard. Pasting it into the app you were typing in is different. The clipboard manager has to press ⌘V in that app for you, and macOS lets an app send keystrokes to other apps only once you allow it. The switch is in System Settings › Privacy & Security › Accessibility.
The first time you choose an item without that permission, SSPaste asks whether it should paste directly. Its button opens that list in System Settings, with a bar beside it that you drag SSPaste from into the list.
Other clipboard managers give the same reason. Paste’s help says it only sends ⌘V to the app in front, and ⌘C when its Paste Stack is in use. Maccy’s FAQ answers “Why doesn’t it paste when I select an item in history?” by pointing to the same list.
What Apple says the switch allows
Apple’s page on accessibility access is blunt about it. Allowing an app there also gives it access to “contacts, calendar, and other information”, and Apple asks you to “be cautious and grant access only to apps that you know and trust.”
The App Store version gets less than that
SSPaste from the Mac App Store runs inside Apple’s App Sandbox. An Apple engineer put it plainly on Apple’s developer forums: “In general, App Sandbox blocks use of the Accessibility APIs.” What a sandboxed app can ask for is narrower: permission to post keyboard events. The same engineer explains that it “shows up in the UI as System Settings > Privacy & Security > Accessibility” but doesn’t give complete accessibility access: “It’s just limited to posting events.”
That narrower permission is the one SSPaste asks for. The switch in System Settings looks the same as it does for any other app, and SSPaste’s code has no call that reads the contents of another app’s windows. Everything it does with the permission is in the next section.
What SSPaste sends
One ⌘V, after you choose an item. SSPaste puts the item on the clipboard, closes its panel, waits for the app you were in to come back to the front, and presses ⌘V. If that app is not in front within a second, nothing is sent: the tray opens again and says the item is on the clipboard. If the ⌘V lands on SSPaste itself instead, SSPaste hides and sends it once more, and never a third time.
It does not watch your typing. It hears ⇧⌘V the way any app with a global shortcut does, by registering that one combination with macOS, which then tells it when those keys are pressed and about no others. While its panel is open it also notices a mouse click outside the panel, so that it can close. macOS asks no permission for that, and SSPaste uses only the fact that a click happened.
Leaving it off
SSPaste works without the permission. Choosing an item copies it, and SSPaste tells you to press ⌘V yourself. If you would rather not be asked, turn off Into the Active App under Paste Items in Settings › General. You can also turn the switch in System Settings off again at any time.
What you are taking on trust
SSPaste is closed source, so for what its code does you have my word and this page. What you can see for yourself is the effect: with the switch off, SSPaste cannot paste into other apps at all. The privacy policy lists the two occasions on which SSPaste goes online, and neither has anything to do with this permission.