I am adding this for anyone in the future that reads this thread.
Here is all that I've learned in digging into this issue and getting a complete distance between points call.
Our first issue stemmed from the static nature of RasterCatalog. Changing the rasters that this is based on does NOT change the raster inside the RasterCatalog. It turned out that ours had an ancient version that was nowhere near a coastline map. Lesson Learned: Rebuild the RasterCatalog EVERY TIME you change the Rasters it is based on.
The Distance Raster with weights added becomes a rather cumbersome thing to work with. Look at the following scenario:
Original value of raster is 1 total distance I want to look at is 117 km. Cell size is 1 meter.
If the raster is now a weighted value of 48, then the total distance I want to look become 117 km * 48!!! So distance in the CostDistance method is not the cell distance but the weighted distance, apparently adding the value in each cell until the sum of each cell = the value passed for total distance. Even if the cell size itself is 1 meter!!!
The distance raster is all focused upon a point of origin. So when you call the CostDistance routine you do not want to include the point of origin in that list. if you do you will get one point with a distance of 0. (this even stumped ESRI support)
While many of the methods use the Envelope to restrict their process, the two most expensive ones, setting a value to the raster and extracting a raster without an area within a polygon, ignore all envelope settings and automagically always apply this to the entire raster. Unfortunately for us, we can only shorten this by creating massive overlapping segments and assigning a segment to a specific boxed area. But in doing so we have to be careful (which is hard) that a primary operation area does not exist in the wrong overlapped area. (in other words all of our overlaps have to be carefully chosen to not contain any primary points of interest!) The reason for this is we navigate the RasterCatalog choosing the correct raster based on where the Coast Guard station chosen exists. To further complicate our process, the overlap must allow us to navigate up to 120km away from our point of origin without running off the edge of the map and not overlapped with other primary points of interest. Sheesh.
The only other things I've learned is that it is easy to math to the raster but when you want to either 'poke a hole' in the raster (blockages) or set a donut with a value and the inside of the donut having a value of 1 (delays like a lock) you end up with a complex combination of tools and ArcObject calls. Which leads to the final lesson learned: ArcObjects cannot do everything. So I am occasionally forced to do things in the slow, cumbersome tools that were all written in python. I also learned that ESRI tool developers knew nothing about maintaining consistency. Sometimes they took a raster database at other times they needed a raster and occasionally they needed a featureset. And they don't return the data in the same format that they require as input! So if you need to use a second tool that wants the output of the last tool in a different format then you have to go through the hefty exercise of finding out how to do that.
Confused? Don't worry, it's ESRI.