First and foremost: Stop using JWT for sessions and why your cannot hack it into working.
I do not have the knowledge to properly argue against this, apart from reciting things like "do not invent your own security", but this seems like a horrible disaster waiting to happen.
So your primary question is how to convince your coworkers that this is a bad scheme?
If telling them they shouldn't be writing their own cryptography isn't enough, tell them instead how their custom solution is more expensive, complex and less secure than the alternatives. See below for alternatives.
What seems problematic to me is that the ciphertext is not signed so if the user can forge the request somehow he still has access to all other user data.
Signatures are asymmetric (expensive) and are (generally) larger than symmetric MACs. You'll be better off using symmetric solutions instead. Similarly encrypting is not authenticating and copy-pasting a ciphertext is not demonstrating an authority.
Is it possible to somehow forge a request here? For example by messing around with the bits and see if the server throws an error (or what kind of error).
If these object IDs are encrypted using CTR mode, then incrementing the ciphertext still gives you the next ID. If instead the object ID is encrypted using a PRP, then you can guess a random ID in $2^{b/2}/n$ guesses assuming a $b$-bit block-size and $n$ valid IDs exist. If you have 1 billion IDs, then this is only $18446744 \approx 2^{24}$ attempts. (can someone verify?)
Cryptographically this is weak. In practice you should have rate limiting and should slow down users who make repeated attempts for invalid IDs so this might not be too bad, but with only $18$ million guesses for $1$ billion possibilities this really depends on how sensitive you think these apples are. If they have no value, no one will try. If they are sensitive, it'll be only a matter of time.
I'm looking for easy-to-understand reasons on why it is a bad idea to do this to present a solid argument to my colleagues (or be convinced that it is not).
It is custom, slow, expensive, unverified and unnecessary!
Alternative 1: per-user isolated sets of apples
If apples cannot be shared between users then only display the ID relative to the user in question. I.e. If Alice has $3$ apples, they are $0$, $1$, and $2$. If Bob has $2$ apples, they are $0$, and $1$.
Additionally this can be bound to HTTP cookies such that malicious JavaScript cannot exfiltrate the JWT stored in LocalStorage. Better yet, this doesn't rely on JavaScript at all.
Alternative 2: capability-based sharing of apples
If apples can be shared between users, look into capabilities and macaroons.
A capability is an unforgeable, unguessable and communicable token of authority. You can only acquire a capability from someone who already holds it. Capabilities are stronger than cryptography, but they rely on trusted systems. Using keys-as-caps, cryptography can emulate a weaker form of capabilities based on knowledge (not possession). Macaroons are a cryptographic capability relying only on a secure keyed-hash (HMAC). No expensive asymmetric encryption or signatures.
Example macaroon (approximate example, see the paper for better definitions):
$$\begin{aligned}
s &= \text{new_macaroon}(\text{server_secret}, \text{nonce})\\
&= (nonce, \text{HMAC}(\text{server_secret}, n))\\
a &= \text{add_caveat}(\text{authority}, \text{caveat})\\
&= (\text{authority}_0, \text{authority}_{n-1}, \dots, 0 \| \text{caveat}, \text{HMAC}(\text{authority}_n, 0 \| \text{caveat})\\
i &= \text{invoke}(\text{authority}, \text{message})\\
&= (\text{authority}_0, \text{authority}_{n-1}, \dots, 1 \| \text{message},\text{HMAC}(\text{authority}_n, 1 \| \text{message})
\end{aligned}$$
$s$ is an unrestricted credential. It is always valid. Technically the server could revoke it by the $nonce$, but this is not assumed. $a$ has additional caveats added. I.e. To expire the credential after some time, or to limit the objects or functions that may be reached or called. And finally $i$ invokes the authority to send some message to the server. If all caveats evaluate without failure, then the message is approved and evaluated.
Any time the un-invoked authority is shared we must use a secure transport to prevent a MiTM from learning the secret key. When invoking we reveal only public information and a proof binding the authority to the message. Conveniently this also makes CSRF tokens obsolete, but it does not prevent replays as-is.
Notice that macaroons do not assume the system has "users" or that revocation or expiration are required. The server is responsible to selecting the initial caveats, and the user may add any caveats they want when they share the credential. If Alice shares her credential with Bob to access an $\text{apple}_5$, then Bob can access only this apple and not any of Alice' other apples. Nor does this credential assume signatures.
Signatures only make sense when a large (or unknown) audience needs to verify the integrity offline. Your server is the only one producing and verifying these credentials correct? If your users need to authorize a third party service to perform some actions on their behalf, they share a provisioned credential with any caveats they want. Additionally, the user can include a special kind of caveat that pings back to their own server to ask for permission to perform some action. This enables the user to revoke the capabilities.
The users can add caveats and distribute them offline without interacting with your servers.
