One limit that I reached lately was in the Q3 engine the limit for entity brushes. I don't know whats the limit in newer Q3 engine games like SoF2 or JK2, but in EF it's just around 255. I need more!  

I've found that in HL, you start getting wierd stuff (teams swap models etc) when there are too many entities yet you're not at the entity limit. I guess that depends on what type of entities you have. In LZ, I have a simple tracktrain helicopter and an AI helicopter and I guess that the AI helicopter sucks a lot of cycles.

As for big maps, I love 'em but only as Flix says, in a big community on a full server. I've done too many big maps that get run on small servers that I'm learning that you have to map realistically for the size of your community and grow the maps later on rather than start out with the huge maps that just don't work with fewer players. I guess, for multiplayer anyway, you need to be truthfull to yourself about how big a community you'll get playing your maps in order to make stuff that's successfull. sorry, got off topic there!

*Anyway*

I think the most limiting thing about the HL engine is its entity system. The entities seem to have been created for specific purposes (SP) and then grown spines as the mp mod community grew. There's a lot of simple stuff that could be done to developed chained sequences but sooner or later you're going to run into and entity that doesn't have a feature that other entities have (i.e. reseting properly).

I don't have any experience with other engines but that's how I feel for HL.

the worst thing is learning to do something the WRONG way...

that's happened to me a few times.  Good docs are a must.

the most limiting thing as a mapper using HL is max-polygons... ie r_speeds, you just can't make outdoor areas very detailed unless you're running it on a supercomputer.

Engine? No... Some improvement in the lastest Q3 engine and the ydnar's q3map push the limit somewhere else.

Texture? Kinda... But the limit is 1024*1024 for a .tga, which is kinda large. Bump mapping and light shader is largely underuse.

Script? depend. Don't think so. Shader side, I would like some improvement.

Map? So far, no... Of course, multi-gravity and some environment control would be better.

Tutorial are AFAIK, just the right number so far. Some point are hard to find, but what do you want.

The only limitation, is that most people don't try to go far and push the limit.

I only have experience with sof2 really, but most of the time there is sufficient documentation. And when that fails (which it didn't for sof2 imo) you can always press F1 for the help docs that come with the software.

Hmm, I ranted and raved and frothed at the mouth about this one. Being one of the Halflife modders, here's some of my reasons for using an old engine (i.e. not moving to a newer one):

1) Large community that plays mods for the game - many newer games take a while to achieve this, if at all. Most games never do. (i.e. large installed base, so that there's enough players for all the mods) -- I don't expect a gamedev shop can do much about that.

2) MOD support out of the box - Halflife excelled here, and newer games (like SOF2) did a good job of catching this one -- the game shouldn't be thought of as the final product IMHO. It should be a 'mod platform' as well as a compelling title. PLAN to support and grow the mod community, design your code modularly, so it's not a nightmare for a relatively inexperienced programmer to mess around. Why halflife's mod community is so large is there's all skill levels of modmakers - from kids who don't know what a constructor is to experienced professional programmers, who just want to try their hand at gamedev.

3) Pipeline to the actual developers - If someone making a mod can't get an answer any other way, they can email someone who actually coded the game, or specifically hired 'SDK/mod' support people. As a mod maker, I shouldn't feel intimidated to email the original developer (unless it's stupid questions about the C++ language, etc.).

4) Willingness to add to the SDK - if the mod community requests a feature long enough, add it to a new SDK, i.e. bring it out of the engine -- where licensing permits.

5) Documentation can be a hassle, but the most successful games in this category were documented by and large by the mod community themselves (halflife, quake i/ii). If a new developer wants to encourage development, a little money invested in documenting your SDK for the mod community may help.

6) Higher poly limits may not be as important as the unwashed masses may think. To be honest, there are plenty of really talented modellers in the mod community, however, there are also plenty of mediocre ones. What good is an engine that can support more polys in a scene if the modellers can't make anything that looks better there?

More important for me to decide to move from halflife to another mod platform would be the ability to support features that we're getting slapped in the face by constantly -- lack of transparent texture (now being added), no support for bump maps, or higher bit depth textures. One of the most talented modellers I work with, just can't get his textures looking right in Halflife, he's done work with more modern engines or in reels where he had access to that kind of stuff.

7) No requirement to learn a new programming language -- this is the #1 reason I've never bothered with Unreal, and don't plan to. I could care less to learn a new language, it's hard enough drilling down into the details of a complex one like C++, which is required in my day to day work. You'll never augment your career possibilities learning Unreal Script IMHO - at least not the extent you will with C++
NOTE: This is mostly because of the HR folks who filter resumes - I as any programmer know that language isn't as important as logical thinking ability, but HR people don't know that.

Yes, this is a 'programmers view', but that's the only one I have to offer the world . Sorry if I blathered on a bit there.