Q:

Does object-oriented programming allows side effects and state changes?

I know that obviously every language has its own characteristics and implementations, but from a theoretical standing point, viewing OOP as an abstract programming paradigm, does it allows side effects? Does it change the program state?
Every object has its own state and an object can change its own state or another object's state. So, is this state the same with the program state? And thus, OOP is not stateless? 
On the other hand, OOP allows for side effects (observable interactions between objects, modify global vars).
So OOP is stateful and allows side effects? Did I got it right? 

A:

There is no universal definition of OOP. It is therefore difficult to make a statement like “OOP is stateful”. There are both examples where OOP involves state and examples where OOP is used without any state. OOP tends to be paired with imperative programming, which certainly allows side effects and mutable state.
There is one line of thought that OOP is about encapsulation. OOP is not needed to organize the program state into smaller records/structs. But if we turn those records into objects and encapsulate this data behind a message-passing interface, we can disentangle the program state, leading to a more decoupled and modularized architecture.
That way the state is still there, but we can look at parts of the state (each object) in isolation. There won't be any outside interference. If outside users want to access or change the state, they will have to call a method that we control. It is now easier to reason about an object. Conversely, outside users only need to know about the public interface and not all internal details, which makes their life easier as well.
So one could say that OOP is a technique for managing program state more easily.
Using OOP for encapsulation like this lends itself well to larger software systems, at least in theory. This idea is not restricted to single object instances in a programming language. One could also view larger architectures as object-oriented, e.g. in a microservice architecture each individual microservice can be interpreted as an object.
In most OOP-ish programs this state management is not done cleanly. Any time you access a global variable or call a static function you are side-stepping the decoupling benefits of only communicating via method calls. This will come back to bite you if you write unit tests for an object – any data flow through static members is data flow you can't intercept, mock, and verify.
OOP is not the only way to manage state within a larger application. Most of these features like “encapsulation” are merely an example of the modular programming paradigm, but there's no clear line between modular and object-oriented programming. Instead of parcelling state into smaller chunks that send messages to each other, functional programming suggests making all state explicit and immutable. The program flow can then be interpreted as state transformations rather than state mutations.

A:

Here's a somewhat heterodox but, I (biasedly) think, interesting perspective.
Originally, my opinion was that state and object identity were not integral parts of OO "in theory", though they are ubiquitous in practice.  It's quite easy (if unusual) to avoid mutable state entirely in an OO language like Java (modulo wanting to use standard libraries...)  For example, Abadi and Cardelli had both mutable and immutable versions of their ς-calculus which was intended to be for OO what the λ-calculus is for FP. Suffice it to say, neither it nor any other "object calculus" has actually managed to claim such a role.
There's basically only one other "calculus" that has gained significance even approaching the λ-calculus' and that's Milner's π-calculus which was designed for reasoning about concurrent systems. My views changed after writing a decent amount of code in a π-calculus style, and particularly when discovering the blue and deep blue calculi which note that code written in the π-calculus tends to look and feel like working in continuation-passing style and endeavors to provide a "direct style" variation of the π-calculus. The result is rather like a concurrent OO language (and one that can smoothly capture the ς-calculus no less). Similarly, even writing code in the π-calculus tends to produce patterns that are very reminiscent of OO-style objects.
This perspective provides a firm footing for many, but not all, aspects of OO languages, and concurrency and OO have been interrelated in a variety of ways (actor model, active objects, the discrete event simulations of Simula, message passing) throughout the history of OO. Of course, most modern OO languages don't emphasize concurrency. Indeed, the vision of OO this perspective suggests looks a lot more like Erlang than Java. Nevertheless, this perspective does entail that mutable state and object identity are inherent. While within a "process" we may not have mutable state, as in Erlang where each process' body is (mostly) purely functional, it's trivial to model mutable state as a process. Similarly, while the π-calculus doesn't have anything like reference equality and it's non-trivial to model it, it's nevertheless clear that two processes are distinct even if they have the exact same definition. (In Erlang/actor terms, they have different "mailboxes".)

A:

I believe that Object-Oriented does allow side effects and state changes but well-designed object systems do it in one relatively small, well-delimited bubble at a time. Actor-based platforms are a good example of this principle followed strictly.
If you look at Alan Kay's account of the beginnings of Smalltalk (the language that introduced the term object-oriented) and early OO languages, whether to ultimately change state or not didn't even seem to be a question back then. It was implied that something had to be mutable in order for a system to run, but what really mattered was how and whether the calling object should be aware of any of it. Namely, the big idea was that objects had an internal memory, one that couldn't be modified from the outside with direct fine grained assignments, but could only be transitioned by calling methods reflecting higher-level behaviors of the object.

Everything is an object
Objects communicate by sending and receiving messages (in terms of objects)
Objects have their own memory (in terms of objects)

[...]
The last thing you wanted any programmer to do is mess with internal
state even if presented figuratively. Instead, the objects should be
presented as sites of higher level behaviors more appropriate for use
as dynamic components.
[...]
It is unfortunate that much of what is called "object-oriented
programming" today is simply old style programming with fancier
constructs. Many programs are loaded with "assignment*style"
operations now done by more expensive attached procedures.
[...]
However, doing encapsulation right is a commitment not just to
abstraction of state, but to eliminate state oriented metaphors from
programming.

(In The Early History of Smalltalk, p. 19, 25)

