2D Engine Design Question

I'd go for the second option if I were you - after all, these parameters are typical game-parameters and have little to do with engine-specific things. A top-down 2D renderer can be used by RTS games as well as RPG games, the core bussiness of the engines are very similar: render a tilemap and render objects on top of it, do some pathfinding and play sounds/music, and possibly some other general tasks. Why would placing such parameters in the engine reduce scripting work? Placing it in the gamecode is a much more natural choice, and I can't see why it would cost any extra time. In fact, I'd argue that, by tieing gamecode into the engine, the program will eventually become harder to manage.
Half-Life uses this approach, for example, and after Valve exposed the gamecode source, a lot of mods were made. A proper design for your gamecode allows for reusable behaviour - for example, all Half-Life characters that were able to speak were derived from the same TalkMonster class, all enemies that operated in squads were subclasses of SquadMonster. Whether or not that structure suits your game is another question... ;)

As for scripting, if you expect a lot of double scripting, then design the scripting language in such a way that it can be avoided. For example, by allowing scripts to be included into other script files (similar to including header files), or by using a css-styled approach, with scripts for overall behaviour and various levels of scripts, that can override parts of the higher-level scripts. Total Annihilation used such an approach, and it caused a whole unit modding community to arise. If you expect your game to take a lot of tweaking to get right, or if you are planning to frequently add new game objects, then this is probably the best choice so far.

I'd go with 2 or 3, depending on how much effort you're focusing on the scripting system. If your system doesn't allow simple inheritance and really does require you to duplicate a lot of code, that's probably a bad idea.

My game's technical design features three or four layers:
1. C++ code that controls the graphics, GUI, sound, physics, etc. libraries and exposes an interface with Boost.Python.
2. Python code that ties this all together into a game engine and exposes a friendlier interface.
3. Python code that represents the game itself: logic (including character skills/stats and how they work), AI, GUI code, etc.
4. Really just an extension of 3, where developers and users can drop in their own Python scripts to add or replace features. Code for items and dialogue can be done at this level, sort of a replacement for the traditional scripting system but vastly more powerful, since it has access to the same engine interface.

I'd call 1-2 the engine and 3-4 the game. There's some fluidity in these layers, of course. Do you put a terrain generator in 2 or 3? If I need to add another C++ module for when I have to fix a bottleneck, where does that fit in?

It started as all open source, but I'm seriously considering an approach where the engine part is BSD-licensed open source, and the game is closed. It might help enforce good design!