[SalesForce] Why we are allowed to pass sObject in queueable

Things that are executed asynchronously are serialized into a binary format at the moment they are called, then placed into a queue. This queue is then executed later. I wrote a proof of concept for this once before, but I don't have it handy.

Therefore, it's easily possible that the records could change between the time the function is called and when it executes. For example, workflow field updates, rollup summary fields, and formulas might change by then.

It's generally better to query a record during execution of an asynchronously executed function rather than depending on it not changing between when it is queued and executed.

Your logic is slightly flawed. All async code can run in to stale data. The difference between Batchable, Queueable, and Future methods is how they're designed to behave. Batchable calls were designed to allow for heavy asynchronous processing. But, it was the only asynchronous code at one point, and it was too "heavy" in terms of resource usage, and had a lot of baggage associated with it. It required a long time to process and was often used only to handle callouts or things that were slightly longer than a normal transaction could handle.

So, next came future methods. Unlike Batchable methods, they were lighter on resources and perfect for doing that job that Batchable was doing before, but much more efficiently. Unfortunately, it was too efficient. You didn't know when the job was done (no Job ID), and it only had a limited amount of space to store data (the reason why it only accepted primitives and collections thereof).

In response to feedback, a third version of asynchronous code was designed: Queueable. It was lighter than Batchable, but it gave you a Job ID and let you store complex data patterns. The lesser resources it used compared to batchable also meant higher limits. Queueable was meant to be a hybrid between the limited future methods and the resource-hungry Batchable interface.

So, to get back to your question: you should always avoid passing in entire SObjects, especially if they may change between serialization and execution. If you need heavy processing, you probably want Batchable, while if you want normal-sized transactions with increased limits, you probably want Queueable. Of course, you can still use future methods if you don't need to monitor the results of the execution, and they'll continue to work for the foreseeable future.