How does a server side programming language handle this type of request?
Most programming languages don't deal with this. Instead, this problem is generally solved by databases, which is designed to solve these kind of issues using transactions.
Now the question shifts to, how do databases solve this? A variety of ways, older relational databases used to lock records so that only one request can modify a particular value at the same time. Modern relational databases used a technique called MVCC (multi version concurrency control), which used a log-based data structure to let multiple readers and multiple writers access the same record safely and concurrently, and to detect and rollback when there is update conflicts. Some non relational, distributed databases drops the requirement for strict data consistency, and instead permits inconsistent data temporarily, with "eventually consistent" guarantee.
At the most basic level, the primitive used a CPU instruction called compare-and-swap. At a higher level, you have a data structure a write ahead log/journal, which keeps track of the changes in an append-only file before the changes are incorporated into the current data structure. At distributed infrastructure level, you have various consensus algorithms like Paxos or Raft, and a number of specialized distributed ledger to ensure consistent accounting across multiple machines.
YouTube view counter likely employs a distributed infrastructure with "eventually consistent" counter rather than a fully consistent counter. This means that at any one time, the counter on each replica may never reflect the real universal view count, but supposedly if the world stops accessing YouTube and the system are given a bit of time to reach a stable state, the distributed infrastructure would eventually converge to the real view count.
can two requests access a variable or any sort of data and change its value at the same time? is the first arrived request to be handled first and then the second waits for its turn?
With databases that employs locks, yes, only one request can access one data at a time, the request that comes later had to wait for the first one to finish. With databases that employs MVCC, handing multiple requests concurrently are possible, but write conflict gets detected and the request that commits later get aborted. With distributed, eventually consistent counter, multiple writers are possible but you sacrifice a consistent view of the data.
Question:could it happen only by chance or 100% of the time?
It happens all the time, not necessarily 100% of the time, but often enough that when an application need to scale, you need to take them into account.
Question:What type of vulnerability is this? does it have a specific definition?
When handled well, there should not be vulnerability. Applications need to define the level of consistency guarantee that it needs. Financial applications generally need strong consistency guarantee, while YouTube view count can afford a looser consistency for greater performance.