I am creating a Chrome extension that checks gmail inbox.
I'm using the xml feed url to fetch it: https://mail.google.com/mail/u/0/feed/atom
For updating, I'm using chrome.alarms API that sends GET request every 10 seconds. Is that too much? If not, could I change it to 1 second too? How much load does their server have to handle in order to send me the feed's information?
You can get updates with a lot less latency if you use a different technique such as "long polling" or "web sockets". This is very useful for things where you want no lag, like a real-time chat, a web-based video game, or a time-sensitive process like an auction or ticket/order queue. It might be a bit less important for something less real-time, like email (see the last paragraph in this answer).
Gmail seems to have an API that is explicitly designed for fast notifications.
Most web servers can stand up to being called once a second without killing their site. If they can't, then they have some serious security problems (Denial of Service attacks, or worse if their site is buggy enough to suffer data loss when overloaded).
Google has big servers, and protection, so you don't really need to worry about what they can handle, as long as they don't block you. Google may rate limit calls to their gmail API, and you may end up getting a user throttled if you call their API more then they prefer. Consult their documentation to find out what their rate limiting policies are.
To more generically answer you question, normal HTTP isn't really optimized for frequent polling for refreshed data. You can make a decent number of requests (even upwards of one a second or more). You probably won't kill the computer or browser or even make them run slowly, as long as the request and response payload data is small enough, and the processing/dom changes you do with the response are minimal when the data comes back unchanged.
Assuming you don't violate per-site rate limits, and have small data payloads in the request you are making, then the biggest problem is that you might still be wasting a lot of bandwidth. For people who have to pay by the minute/megabyte, this is a problem. This is much more frequent in Europe than in the United States (although it is also frequent on cellular devices).
Consider if you really need email to be checked every second. Would every ten seconds be fine? Maybe every minute? Maybe your app could do a refresh when you send mail, but take longer to check for new mail when it is idle? Think about what use cases you are solving for before assuming everything always has to be constantly updated. What would waiting a few extra seconds break? If the answer is nothing, then you can safely slow down your updates. If there are use cases that would be broken or annoying, then figure out why it is important. See if there are even better ways to address that use case, or if updating frequently is actually the right answer. Sometimes it is!