コンストラクタの役割、説明

コンストラクタが便利なのではありません。
クラスが便利なのです。

クラスとは小さな「データとアルゴリズムの集まり」であり、単体で完結する「小さなプログラム」でもあります。
例えばいわゆるトランプのカードのクラスを例に取れば、カードには
・数値（A,2～10,J,Q,K）
・マーク（スペード・ハート・ダイヤ・クラブ）
・自身が「表か裏か」
があり、また行える操作として
・裏返す
・数値を返す（裏なら分からない）
・マークを返す（裏なら分からない）
・自身を表示する（表裏によって表示が異なる）
といった操作が行えるでしょう。

しかしよく考えてください。カードは一度作成したら、数値もマークも変化しませんね？（マジシャンがマジックで使うのは別ですが）
ということは、数値にせよマークにせよ、「作る時に決まれば、あとは変更させない」方がよくなります。
そこで「カードを作る時に数値とマークを設定すればいい」となり、そのためにコンストラクタが活躍します。

まずはクラスをはじめとするオブジェクト指向の基礎をしっかりと学びましょう。

クラスを使う側の立場に立って考えると理解しやすいかもしれません。  
カプセル化にかかわることなのですが、オブジェクト指向の本質の一つはそのクラスを使う側が使いやすいようにして、間違った使い方をしないようにする、ということです(もちろんこれは一つの側面に過ぎないのですが)。
それであまりいい例が思い浮かばなかったのですが、古くからあるJavaの標準ライブラリのjava.io.Fileクラスだと、

import java.io.File;

public class MyClass {
    public static void main(String args[]) {
        File file = new File("C:/tmp/text1.txt");  // C:\\tmp\\text1.txtでも良いが、こちらがおすすめ(/はWindows/Linuxで通用する)
        if (file.exists()) {   // ファイルがあるか？
            System.out.println("file exists.");
            file.delete();  // ファイルを消す
        } else {
            System.out.println("file is not found.");
        }
        System.out.println(file.getParent());   // 一つ上の階層のパスを表示 => C:/tmp
    }
}

という感じで使って、コンストラクタで一旦パスを設定する。
そのあと、そのファイル（またはディレクトリ）に対して、やりたい操作（メソッド）を呼び出す。  
という使い方になります。

上記のようにコンストラクタでファイルの場所を指定します。
もし、コンストラクタがなければ、

File file = new File();
file.setPath("C:/tmp/text1.txt");

と冗長になってしまいますし、
途中で、file.setPath("C:/tmp/text2.txt");と誤って書き換えることがあるかもしれません。

一旦パスを指定すれば、あとはexists()メソッドで存在を確認したり、delete()メソッドでそのパスのもの（ファイルやディレクトリ）を消すことができます。
逆にsetPath()のようなメソッドはなくて、使う側にむやみやたらに無用にパスなどを書き換えられないようにカプセル化して、クラスの詳細を知らずとも、とりあえずこれを使えばこういうことができる、というようにクラスが設計されています。

実際のソースコードはこんな感じで、知らなくてもよい(または外から書き換える必要がない)ようなものはprivateになっています。
Open JDK 1.8 Fileクラス

備考: 今回の件とは関係ないですが画面などユーザの目に触れる部分ではC:/tmp/text1.txtのようなスラッシュ表記は使ってはいけないです。参考

あと、カプセル化に関してですが、
フィールドすべてにgetter/setterをつけるなら最初からすべてフィールドをpublicにしてしまえば実はよいのです(ただし、getXXX()/setXXX()があるのを前提としているフレームワーク等が存在するので伝統的にそうしていることが多いです。このあたりはJavaBeansというのが背景にあって、興味があれば調べてみてください(もう知らなくてもいいかもしれません))。最近だとこの辺りは非常にだるいのでLombokというライブラリで逃げます。

オブジェクト指向が一般的になってから出始めた言語なのでこの辺りは結構古い思想でできてしまっています。ちなみにRubyやPythonだと基本public扱いでフィールドを露出したままのことが多いです(言語仕様的にやりにくいし、思想的に不要というのもある)。

要は、カプセル化は、使う側の人が明示的に書き換える必要のないものはprivateにして書き換え不可にしてしまって、最小限の情報だけ開示するってものです。この辺まともに説明している書籍は昔はあまりなかったです。

余談ですが、あまりコンストラクタを提供するパターンのクラスを見ないぞ？と思って、かつこの辺が理解できましたら、デザインパターンを勉強してみてください。

コンストラクタが無ければ以下のように書かねばならず面倒臭いからです。

CardNumber card = new CardNumber();
card.setName("キング");
card.setNumber(10);
card.setSheets(3);

カプセル化に関して答えます。
カプセル化は変数名を変えると利用されるクラスに想定される影響を考慮されて作られたものではないかと考えています。

ソース1はソース２を抜粋したものです。コメントの意味を考えてください。

///ソース１
private static String name;///この名前をname_1にするとした時を考えてみると？①
static String name2;//この名前をname_2にするとtest2クラスはどうなる？②

①特に何の影響もない
②test2クラスがコンパイルエラー
となります。

余談なんですけど久しぶりにEclipse起動してJava書いてたら細かい文法の制約多すぎやなと思いました。
そのてんPythonはいいね。
そもそもEclipse起動したのJavaSilverの勉強して以来なんやけど・・・

///ソース２
package test;

public class test{

    private static String name;///この名前をname_1にするとした時を考えてみると？
    static String name2;//この名前をname_2にするとtest2クラスはどうなる？
    public static String getName() {
        return name;
    }

    public static void SetName(String name) {

        return name = name ;
    }

}
class test1{

    String  name = test.getName();
}

class test2{

    String s = test.name2;
}