Why should I use MVVM in Silverlight app?

We don't do Unit Test for ViewModel,

With MVVM, it isn't just about unit testing ViewModel. Ideally, your VM should be very thin and only have properties needed by view. So, it isn't really necessary to test the VM.

But, without a VM, how do you do your your feature/functional testing across layers? In Silverlight, to facilitate testing you should use commands, instead of writing code in code-behind files. This allows you to simulate button click and other GUI events while unit testing. Using MVVM pattern along with commands, you can test all of C# code (not xaml), right up to UI (Converter, VMs, etc).

If I provide public methods in a code-behind, they can also provide reusability.

Not going into details of how that is a bad design, I want to ask you, How does that provide reusablity? If you create a user control, then the code-behind class is a control? You want to create instances of your control and use them? This is like saying that why do we need member methods, we can just create public static methods and access them. I have a strong opinion that if we don't want to use the automatic binding provided by WPF/Silverlight, then it is better NOT to use these technologies. And to exploit the full capabilities of binding, MVVM is essential.

why it's loosely coupled?

VM is very much part of your view. It is not decoupled from the view. As I have said, your VM should be as thin as possible with only public properties needed by your view. Your business logic will be decoupled from your view (and VM).

I can answer how I use MVVM pattern. MVVM is better in the following scenarios:

1 If several controls are bound with a single property.

MVVM:

<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>

I can quickly add a similar control or remove an existing control.

Compare with code-behind:

public string IsSomePropertyTrue
{
    set
    {
        //...
        text1.Visibility = value;
        text2.Visibility = value; 
    }
}

2 Instead of a multi-converter

public Brush StateColor { get { if (this.State == State.Edited && this.IsPriority) return new SolidColorBrush(Color.FromArgb(255, 0, 255, 0)); //... } }  

<sdk:DataGridTemplateColumn.CellTemplate>
    <DataTemplate>
        <TextBlock Background="{Binding StateColor}" Text="{Binding State}"/>
    </DataTemplate>
</sdk:DataGridTemplateColumn.CellTemplate>

3 As an item model in controls like ListBox or DataGrid. For example, if I want to create a list of items with a remove button near each item, I will create a ItemView control and a ItemViewModel class.

<ItemsControl ItemsSource="{Binding SomeItems}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <view:ItemView DataContext="{Binding}"/>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

4 Copying a data from one view to another:

public JournalEntryViewModel(SalesOrderViewModel vm) {}

5 ViewModel can inherit CLR-classes and implement interfaces (INotifyPropertyChanged or I

I was an early adopter for WPF and I can tell you what made me choose MVVM (and this more or less applies to Silverlight as well). For the project I was working on, I had to create a screen that allowed users to subscribe to notifications within the system. This was a 3 step process:

1. The user had to search for the item they wanted to be notified about
2. They had to select the item and fill out additional options regarding the subscription
3. The system had to provide a summary and allow the user to confirm or edit the subscription.

After implementing the functionality the first time (without MVVM), I was told that we need to exclude from the search items that were already subscribed to by the user.

After making that fix, I was informed that we needed to give the user a live preview of the subscription based on options.

By then I started noticing that some of these changes could be extracted and made easier if I didn't have to deal with manipulating the UI as I changed the logic. I had never intentionally followed MVVM but I realized that the abstraction that I made closely matched the MVVM pattern.

So this is why I recommend the pattern. It simplifies the task of changing the logic that drives the UI by separating it from the UI itself. I also would recommend that you hold off implementing it until you need it. There is a cost to using MVVM but it is amortized over the cost of changing the UI logic.