Whats the advantage of using tilesets instead of importing the entire image itself ? Is it giving us some sort of advantage (in terms of memory maybe) ? Also, how much of a disadvantage would it be to use whole image instead of tilesets ?
It's simply more convenient. If you store the tiles with ids, then you can easily convert those to coordinates on the texture, so you don't need to store the textures in an array or use switches. You also don't need to rebind the textures if you use an API like OpenGL or DirectX, and you only need a single reference for the textures instead of multiple ones.
It doesn't save too much memory, a couple of bytes at most.
Your question is a bit unclear, but I assume you are asking:
Why render the world of a 2D game using a single texture holding an indexable tileset instead of having the world pre-rendered from said tiles? What is the advantage to building the image of the world at runtime?
There are many advantages to this.
Firstly you are right that less memory is used.
Let's say you're using tiles of 32x32 pixels, you have 100 different types of tiles, your map is 128x64 tiles and 1 pixel is 3 bytes large.
If you were storing the image, that would be 4096x2048 pixels, which is 8388608 pixels, which is 25165824 bytes (~24 MB).
Now imagine you're using the alternative approach of indexing tiles. Having only 100 tile types means you can use a single byte for indexing the tiles, so your map takes 128x64 bytes, or 8192 bytes (8KB). The texture for your tiles is 3200x32 pixels, which is 102400 pixels, which uses 307200 bytes (~300KB). So that's 315392 bytes (~308 MB), which is 79.79 times smaller than storing the whole image. By using the tile method, you use roughly 1/80th of the memory for the exact same map.
This is precisely why older games consoles had special tile-base graphics processors. They'd have a fixed amount of tile data and they'd build the screen buffer using tile indexes. It was incredibly effective.
Secondly, by using the tileset method you can animate your tiles. The other method would require a different full sized image of your map for every frame (even ones that don't change), and if you had individual tiles with different numbers of frames you'd have to account for the fact their animations would be out of sync (a 3 frame tile would loop back to frame 1 whilst a 5 frame tile was on its 4th frame, so you'd need 15 full images to account for that discrepency).
If you use tiles, every tile can be animated individually with minimal detriment. You need only store the number of frames each tile has and you can always find the correct frame by using the modulo operator.
Lastly, (I'm not sure whether this counts as an optimisation or something better, but it's an important fact nonetheless) with the tileset method you only need to draw what's on screen at the time, so you'll only ever need to draw a few tiles per frame. Say your monitor has a resolution of 1920x1080, you'd only need to draw 60x34 tiles per frame (61x35 worst case if transitioning diagonally).
Tilesets (a single texture subdivided into parts each containing other textures) have the advantage that you could render all geometry that used the tiles from a set in one go instead of having to rebind the texture for every tile.
However with bindless textures and texture arrays this is less of an issue.