Hi,
I don't think it helps the BM process to start eg. in bar 2, 3 or 4, as long as the first note is placed on 1111. So instead of your suggested 4 points, my first point would rather be: Before starting the BM process, select your relevant material (MIDI or audio) and move it so the first transient/the first MIDI note starts on 1111. It's not necessary, but it gives a better overview, and at least means that you don't need to occasionally dealing with material before 1111.
The way I start, is always to manually use BM to define the tempo of the first bar (or first few bars). Since the first note already is at 1111, I do this by dragging a line from the BM track to the note that appears in 2111 (or a later bar - corresponding to the source note). By doing this, I don't need to use the extra step with the BMP Counter plug-in - and will also get a more accurate result than that plug-in can offer.
I can't remember having had any problems with beat mapping to tempi below 40 BPM; but then again, I beat map tracks manually, I always skip that suggested part where Logic is analyzing the track for you.
There's a bug in 8.02 that deletes tempo events appearing before your first BM event when you start BM'ing anything with tempo changes before your relevant section. There's a way to deal with this ("pseudo-beatmap" every position that has a tempo event by connecting a line from the BM track onto that same position in the track you'll BM).
When having these few things in mind, I've always been able to get a good result if I avoid human errors.
There are of course some limits to what BM can do; for instance, if you have a project with both audio and MIDI regions, you can end up with a very weird result - since a musical phrase inside an audio region normally is a fixed set of events, internally 'locked' to each other, while MIDI events are not locked on each others positions the same way.
The only big weakness in the BM system is IMO that there's no reasonable way to beat map only a section of a song without risking disturbing what happens before and after that area. Some of these situations can, at least partially, be dealt with by locking (and later unlocking) events to the timeline ("SMPTE"), but I hope we'll see a major update one day which will default to only beat map within the locators (as an option), and lock everything before and after the locators both to the grid and to absolute time position, as if they existed in a separate project. If Logic will get that, it would be light years ahead of where it is now.