УП, це множина, котрій належить ООП ? 

Основне - це в ООП є пізнє зв'язування/поліморфізм. Дженерики лише створюють кілька варіантів функцій/типів, які зв'язуються до запуску програми.
Інкапсуляція - це більше до модульного програмування. Наслідування - навіть не знаю, але ООП без нього може жити, а без поліморфізму - ні.

Так клас теж може бути без статики і методів з побічними ефектами, правилами не заборонено.

Ми всі тут дорослі люди (c) ван Россум.

Взагалі, інкапсуляція включає дві окремі фічі: сутність, що включає дані і методи (модуль чи об'єкт - однаково підходять), та контроль доступу програміста до цих даних і методів, і тут якраз модулі виграють, бо їх для того і придумали, щоб приховувати деталі реалізації. А от Python чи JavaScript безумовно ООПшні, але без приховування елементів.

Якщо під статикою розуміємо те, що static у Java'і, то це більше скидається на інтеграцію модульного функціоналу в класи (і клас, де все static, має більше спільного з модулем, аніж з класом).
А от аналогів нестатичних полів (тобто, тих, що належать екземплярові класу) в модульному підході не передбачено. І навіть маючи такі поля, можна зробити їх недоступними для змін після ініціалізації конструктором, а методи — з доступом до читання полів, але без побічного ефекту в вигляді запису. Таким чином, отримаємо immutable-об'єкти.

До речі, якщо мова зайшла про Rust, то він якраз може добре підказати, в чому різниця між узагальненим програмуванням та ООП, бо компілятор намагається замінити поліморфізм на узагальнене програмування де тільки можна. Отже, нехай у нас є такий код:
https://play.rust-lang.org/?gist=bf5b80 … ition=2015

trait Figure: std::fmt::Debug {
    fn area(&self) -> f64;
}

#[derive(Debug)]
struct Square { side:f64 }

impl Figure for Square {
    fn area(&self) -> f64 { self.side.powi(2) }
}

#[derive(Debug)]
struct Rectangle { height:f64, width:f64 }

impl Figure for Rectangle {
    fn area(&self) -> f64 { self.height * self.width }
}

#[derive(Debug)]
struct Circle { radius:f64 }

impl Figure for Circle {
    fn area(&self) -> f64 { std::f64::consts::PI * self.radius.powi(2) }
}

fn print_figure<T>(f:&T) where T:Figure+?Sized {
    println!("Figure {:?} area = {}", f, f.area() );
}

fn main() {
    let s = Square{ side: 3.0 };
    let r = Rectangle{ width: 2.0, height: 6.0 };
    let c = Circle{ radius: 2.0 };
    println!("Generic calls:");
    print_figure(&s);
    print_figure(&r);
    print_figure(&c);
    println!("Polymorphic calls:");
    let v:Vec<&Figure> = vec![&s,&r,&c];
    for f in v {
        print_figure(f);
    }
}

Компілятор сформує 4 різні реалізації print_figure: для типів Square, Rectangle, Circle та для trait object-а Figure. Trait object складається з двох посилань: на реальну структуру та на таблицю віртуальних функцій (у цьому випадку - area та fmt з Debug). Відповідно, перші три виклики area та fmt будуть неполіморфні; а от у циклі буде викликано саме поліморфну версію.