Why Story Points cannot be starting from 10 , 20 , 40, 80 (higher number value)

can a team decide to go with 10,20,40,80

Would doing so improve their ability to forecast how much work they can take on in a Sprint?

Back when I was a developer, I used to (half-jokingly) threaten to not estimate anything for less than 1,000,000 points unless the manager would stop using velocity as a performance metric.

Actually story points are an optional practice, and there is no universally agreed way of using them. If a Development Team find it helpful to estimate with the numbers that you provide, then of course they can do that.

But what is the purpose of having every value as a multiple of 10? Wouldn't it be easier to just use 1,2,4,8, etc?

Could having such large numbers (and therefore large gaps between them) encourage teams to pursue the level of precision that story points are intended to discourage?

In reality you could use anything you want to estimate such as t-shirt sizing (extra small, small, medium, large, extra large, extra extra large, etc).  The modified fibonacci sequence was originally used to show that there are incremental differences but not necessarily doubling in size each increment.  Your suggestion of 10, 20, 40, 80, 160, 320 indicates that each increment is twice the size as the previous.  There is technically no problem with that since story points are nothing but estimates( i.e. guesses made based on the information you have available).  So whatever your team feels is best way to represent their estimates. But I do echo the same questions that @Simon Mayer. 

As they should be relative sizing, I would not go with 10, 20, 40, 80... as it would always be double, but of course you could go with 10, 20, 30, 50, 80, 130... using Fibonacci multiplied with 10, if there is an issue going below the 10 points

Which is easier.

(1) Hello Developers. How many of these refined Product Backlog Items can you fit into the next one week Sprint?

(2) Hello Developers. I want you to use t-shirt sizes and Fibonacci numbers and assign arbitrary values to these user stories in [Insert Tool Name Here]. And if you cannot all agree, lets then use Fist to Five to figure out the outliers, and then we will talk to the outliers and convince them to switch their vote. And if any of you don't document this in [Insert Tool Name Here] we will need to have a chat.

The simple answer to your question is that the team can estimate however they want! No one should tell the DT how to estimate. As long as the process chosen is understood by the team and supports a common language, you can do anything you like.

Why don't you try using the numbers you proposed, then evaluate it in the Sprint Retrospective? If it helped, great, if not, try something else :).