I'm a big fan of line based collision, keep meaning to make an example but time is short these day unfortunately.
What I do is store the angle, and radius of a series of points that connect to form an outline of whatever sprite. With this, it's probably best to have the sprite pivot right in the middle, even if it means bigger images than you'd normally use. By storing the angle and radius, rather than the X and Y offset, it's possible to have practically free rotation. With pixel based collision, rotation is a complete nightmare - with this technique, rotation is free, so is scaling. I would store the radius as a 0.0 to 1.0 range, so that it has no bearing on scale, the actual XY coordinate of each point can be calculated by simply multiplying the 0-1 radius with SIN and COS.
The complex part is really making the editor - the code for this simply falls together once you have 'someones' line to line collision function. By someone I mean Mr.Picone there - he has all sorts of collision snippets. I tend to have an array of lines for static collision and enemy sprites, then check the player sprites own collision data with that. It is fairly straightforward to optimise things, last time I just built up the array with the static level collision data, then bookmarked the array position and reverted back each time, replacing the enemy collision data.
Benefits though, well besides free rotation and scaling, there's circle - line collision too, very handy. Also, you can work out which line got hit and react depending on that, maybe a ship has a weak spot that destroys it instantly. It can mean the ability to add decent 2D physics, rotation based on the point hit for example.
I suggest that you find a good, fast line collision function, and try making an editor. It's a beautiful technique once it's set up, and if your using GDK then you really have to know it inside and out.
One other option for building levels would be sprites themselves, with the same collision system. This would allow for a very free design, using big sprites for the ground, rotating them to save on GFX memory. Again though, the issue is the time it takes to make a good editor - at least with tiles, you have lots of easy options for editing. Myself, I would prefer to have the sprites, maybe get them layered, animated even - tile based games can be a little lifeless compared to more modern engines. A good example would be Aquaria.
The only project I've done using some of these techniques is an old 2D shoot em up, I'm sure the code layout is horrific but I'll have a look, might be worth uploading the source.