how important is to follow process

The sub-tasks are usually assigned to the person who works on the story as a whole, majorly.

Might that explain why the team find little reason to collaborate, and little reason to communicate with each other effectively using a board?

When I ask them for status in daily status meeting that why the status was not moved or why subtasks were not created, they say that we are telling you verbally. 

If you are asking them for status, in something you have called a daily status meeting, then they are indeed doing so, verbally. Are you sure, however, that status is really what is needed?

I am an SM, and I have a hard time having the team to follow simple processes. For example, using JIRA religiously.

Religiously? Not sure this is right approach. I mean, there has to be a certain discipline in support of the value creation, but insisting too much on process without explaining the rationale behind it, the benefits in terms of transparency and workflow, etc isn't going to change behaviors.

how important is to follow process

Don't forget about the first of the four Manifesto values.

I'd like to break this down a bit.

I am an SM, and I have a hard time having the team to follow simple processes.

As a Scrum Master (or anyone in a coaching and facilitation role), why are you trying to "have" your team follow processes?

In some situations, there may process requirements imposed on the team for compliance and perhaps the Scrum Master is the right person to ensure that these requirements are specified in an appropriate manner and level of specificity and that the team understands them and can include them in their way of working. Generally speaking, though, a Scrum Master should let the team define its own process within constraints.

For example, using JIRA religiously. Be it changing the status of the stories from TO DO to in progress when they start working on a story or be it creating subtasks in a story.

Does the team understand why this is necessary? If it's not necessary, why is it being imposed upon the team?

This goes to the point that the team should own their way of working. Perhaps they should be allowed to work like this and when stakeholders want to know information, deal with those requests. They can be taught that updating the status of the work in Jira can help give stakeholders information and they won't need to field requests. However, they may also find that some things are not necessary.

Something else to consider, especially when talking about Jira, is integrations. Automating workflows is a good idea. Jira integrations with a number of tools and you can, for example, update the status of issues when something happens in another tool. An example would mean that a Jira issue can automatically move to an in progress state when a branch is created or to a code review state after a pull request is open. Many tools can integrate with Jira, so as work naturally happens, the state is reflected in Jira. There are also different plugins that can enable other actions automatically.

Ideally can someone please tell me when to create a subtask. Our version is:-

if they have a story, let's say of creating a UI, worth 13 pointers. We create sub-tasks in a way that we divide the story into smaller chunks in a stepwise series. Like if some handshaking needs to be done with another application or some tables needs to be created. The sub-tasks are usually assigned to the person who works on the story as a whole, majorly.

When does the team want to create subtasks?

Personally, I've found subtask issues to be more trouble than they are worth in most cases. Often, I'll just enumerate the work in the issue itself (in the description or a comment). This is even more true if the subtasks are not going to be assigned to people other than the parent level issue. If some work needs a specialist, then the added visibility of a subtask may make sense. Otherwise, I find them to be overhead - the status of the top level issue is what is most interesting, in my experience.

However, it's really up to the team. If the team finds that creating subtasks is worthwhile, they should set the criteria for using subtasks. Perhaps it can even be up to the individual doing the work. Unless there's a good reason to enforce this, the team should choose how to work.

When I ask them for status in daily status meeting that why the status was not moved or why subtasks were not created, they say that we are telling you verbally. They don't consider all of this as of utmost importance. i am not whether should i push them or not. Shall I let go of not having the subtasks created ?

What is a "daily status meeting"?

A few thoughts here.

The first thing that comes to mind is that, in Scrum, the Daily Scrum is explicitly not a status meeting. It's a planning and coordination meeting. The team has a Sprint Goal that they committed to during the Sprint Planning and needs to, on a regular basis, evaluate where they are in relation to accomplishing the Sprint Goal and what needs to happen to achieve it. That is the purpose of the Daily Scrum.

I do agree with you on one aspect of this, though. Going into the Daily Scrum, the status of the work should be visible and accurate. The Daily Scrum is timeboxed to 15 minutes, which isn't a lot of time if you are going to add "update the status of work" to the coordination and planning that is already required.

if they have a story, let's say of creating a UI, worth 13 pointers. We create sub-tasks in a way that we divide the story into smaller chunks in a stepwise series. Like if some handshaking needs to be done with another application or some tables needs to be created. The sub-tasks are usually assigned to the person who works on the story as a whole, majorly.

In India, the subtasks are not assigned to other team members, as such.

Is it the country's law or your team's rule ? Hehe :-D Just wanted to state why we are generalizing it over the country. 

Ok coming back to the problem, Does the development team able to reach their sprint Goals ?

From Guide -

They are self-organizing. No one (not even the Scrum Master) tells the Development Team

how to turn Product Backlog into Increments of potentially releasable functionality;

What do you & team think can happen if they work collaboratively on sub-tasks together instead of one person working on entire story? What do you think how transparency, inspection and adaption will work within the team? 

When I ask them for status in daily status meeting that why the status was not moved or why subtasks were not created, they say that we are telling you verbally. They don't consider all of this as of utmost importance. i am not whether should i push them or not. Shall I let go of not having the subtasks created ?

Is this meeting different from daily scrum ? If yes then why there is need for them to provide the status. The problem as per me is with the team having the individual sprints which brings a less coordination and collaboration. This leads to reduced transparency & lack of interest to make it visible within team.

correction 

Is this meeting different from daily scrum ? If no then why there is specific need for them to provide you the status. The problem as per me is with the team having the individual sprints which brings a less coordination and collaboration. This leads to reduced transparency & lack of interest to make it visible within team.

if they have a story, let's say of creating a UI, worth 13 pointers. We create sub-tasks in a way that we divide the story into smaller chunks in a stepwise series. 

How do they know what tasks are needed and the sequence of those tasks if they haven't started working? I can see identifying the first, possibly second, in order to get work going. But from there on each "task" is determined based on what has been learned from the previous tasks.  "stepwise series" always gives me bad flashbacks to waterfall and how it so frequently went awry. 

Why does the team even create sub-task? If the Development Team is actually using the Daily Scrum to discuss the work that has been completed since the last time they met and the work that is forecast to be done by the next time they meet, do you really need to document that work?  I have had more than one team that found sub-tasking to be a waste of time because they were in constant communication. Instead of moving sub-tasks across their board, they moved the Story. Progress or lack of was discussed daily so it was very apparent to the Development Team. They could communicate any important information to the Product Owner and Scrum Master if there was need for them to be involved. Otherwise the Product Owner and Scrum Master respect that the Development Team is doing the right thing.  If the Sprint Goal is missed and the stakeholders, Product Owner, Scrum Master find out about the situation when the Sprint Review occurs that becomes the first topic of the Retrospective. All of this depends upon the Scrum Team understanding and respecting the purpose of all events.

As for maintaining Jira, @Thomas' idea of integrating and automating is a great idea. And your development team would probably be excited about doing it because it is technology in action. 

I want to also remind you that a Scrum Master is not a Project Manager.  You aren't responsible for gather status and reporting it.  You are responsible for serving the team by helping them understand the Scrum framework and the benefits of everything described.  It is up to the Scrum Team to radiate information to anyone that can benefit from it. I usually coach to provide all information to everyone and let the individual determine if it is something that they are interested in.