Inflate into "this"?

Question 1

@scriptocalypse is generally right, but subclassing some layouts and inflating custom layout to this class helps to separate different abstractions. There are so many bad tutorials, in which everything is done in the Activity. I see that the world's new comming programmers will code only crap looking applications.

With custom layout you can do in Activity only such a thing:

medicineView.putMedicine(medicineList);

instead of all crappy adapter creations and looking for views...

Firstly you should create some view for your custom View:

<RelativeLayout ...>
    <!-- You put all your views here -->
</RelativeLayout>

Secondly if you are sattisfied with your view, you should change the root to merge tag:

<merge ...>
    <!-- You put all your views here -->
</merge>

This is very important. We begin design with RelativeLayout tags in order to IDE know how to draw layouts, and how to do completions. But if we leave it as it is, we will end up in two nested RelativeLayouts it will be something like that in the end:

<RelativeLayout ...>    <!-- That is your class -->
    <RelativeLayout ...> <!-- This is inflated from layout -->  
        <!-- You put all your views here -->
    </RelativeLayout>
</RelativeLayout>

If you change your layout to "merge" then it will look like this:

<RelativeLayout ...>    <!-- That is your class -->
    <merge...> <!-- This is inflated from layout -->  
        <!-- You put all your views here -->
    </merge>
</RelativeLayout>

and will be merged to its root:

<RelativeLayout ...>    <!-- That is your class, merged with layout -->
    <!-- You put all your views here -->
</RelativeLayout>

At the end you must subclass demanded View or ViewGroup:

public class CustomView extends RelativeLayout {
    public CustomView(Context context) {
        super(context);
        initialize();
    }

    public CustomView(Context context, AttributeSet attrs) {
        super(context, attrs);
        initialize();
    }

    public CustomView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
        initialize();
    }

    private void initialize() {
        LayoutInflater inflater = LayoutInflater.from(getContext());
        inflater.inflate(R.id.your_layout, this, true);

        // find your views, set handlers etc.
    }
}

Usage

Just like @scriptocalypse already said. In another layout you use this like that:

<SomeLayout>
    <com.foo.CustomView>
</SomeLayout>

Question 2

First, to answer your main question:

you would not want to inflate an XML RelativeLayout into your RelativeLayout class. You'd extend RelativeLayout and then declare an instance of your RelativeLayout in an XML file, like so:

// com.foo.MyRelativeLayout.java
public class MyRelativeLayout extends RelativeLayout{
    /**
     * Implement MyRelativeLayout
     */
}

and...

// layout_example.xml
<?xml version="1.0" encoding="utf-8"?>
<com.foo.MyRelativeLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent" >

    <!-- Put More Views in here... -->
    <TextView
       android:id="@+id/customer_textview"
       android:layout_width="wrap_content"
       android:layout_height="wrap_content"
       android:text="@string/customer_name_placeholder" />
    <!-- and on... -->

</com.foo.MyRelativeLayout>

But more to the point, if you're using the XML to lay out your file, you don't need any of those instantiations or .addRule() method invocations inside your MyRelativeLayout file because you've done it declaratively in XML instead.

To answer your second question of "Why do you want to use XML anyway?"

There are many reasons. Maybe these apply to you, and maybe they don't, but they're ones that I can think of fairly easily that have been relevant in my work.

You don't actually have to create a new layout file for every separate screen size or use case. For the most part, a single layout file will suffice for most screens. You might find that you will have size/resolution/orientation specific dimens.xml or style.xml files, but unless you want a dramatically different arrangement for your different possibilities then the layouts themselves don't repeat themselves too often.
You can use a visual editor. This is important if you're working in teams, and your teammates don't like to or want to use only Java to lay out their screens. While I and others gladly create View and Layout subclasses to fit our needs, I know of literally nobody who prefers to use Java as their primary layout language. Finding people who will work with you (or a job where everyone else uses the XML tools) could be challenging.
If you're creating tools for other people to use (like the above-mentioned folks who prefer XML) you can actually give them custom attributes to work with, that make positioning and layout more powerful. These attributes could be hard-coded in the XML, or they could be references to any of the other Android resources (drawable/string/color/integer/boolean/etc...). As a contrived example, but one based on your code, you could give your users the ability to specify a number of buttons to create rather than rely on the N_BUT variable. You could give it a default value, but offer users a way to change it in XML.

Here is an example:

 // somelayout.xml
 <?xml version="1.0" encoding="utf-8"?>

 <com.foo.MyRelativeLayout
     xmlns:param="http://schemas.android.com/apk/res-auto"
     style="@style/MyRelativeLayoutStyle"
     param:numberOfButtons="3">

 </com.foo.MyRelativeLayout>

and in a different file...

//attrs.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <declare-styleable name="MyRelativeLayout">    
        <attr name="numberOfButtons" format="reference|integer" />
    </declare-styleable>
</resources>

and in your MyRelativeLayout, you access those attributes from the AttributeSet in its constructor (the one called by Android when it uses XML to create a layout).

Using the style="@style/foo" syntax can allow you to create "classes" of styles that can apply to all kinds of views without actually making a View subclass. Let's say you know that you always want to have a set of parameters that hold true for all your Button elements but don't want to subclass Button.

For example:

// styles.xml
 <style name="BaseButton">
     <item name="android:layout_width">match_parent</item>
     <item name="android:layout_height">wrap_content</item>
     <item name="android:focusable">true</item>
     <item name="android:clickable">true</item>
     <item name="android:background">@drawable/bg_common_button</item>
     <item name="android:textColor">@color/white</item>
     <item name="android:textSize">@dimens/base_button_text_size</item>
 <!--  ^^ that dimen value could vary from screen size to screen size, but the style likely won't -->
 </style>

// button_layout.xml
 <Button
   android:id="@+id/styled_button"
   style="@style/BaseButton" /> <!-- and you're done -->

// some_other_layout.xml
 <LinearLayout
   style="@style/BaseLinearLayout">

   <Button style="@style/BaseButton" android:text="Button1" />
   <Button style="@style/BaseButton" android:text="Button2" />
   <Button style="@style/BaseButton" android:text="Button3" />

 </LinearLayout>

If you would like to instantiate that button using code, then you can use the LayoutInflater to inflate that specific button's layout and use that wherever you want. In fact, you can create all manner of components in XML and then inflate them at runtime.

LayoutInflater inflater = LayoutInflater.from(YourActivity.this); 
Button theInflatedButton = inflater.inflate(R.layout.button_layout.xml, null);

Of course, the canonical example is ListViews and the items that you wish to populate them. You'd create a listview item layout xml and then inflate that whenever your Adapter is in need of a new convertView instance.