This is very similar to what our output looks like from the path distance tool incorporating a dem, vertical raster, and vertical factor specification (which is basically what you are trying to do with your resistance layer but it differentiates between uphill and downhill movement). It may just be what's expected given your elevation range and resistance weightings. But, based on a quick look at your DEM and output there appear to be a number of things that could be causing your results to not appear as you might wish and that you may want to take a second look at to be sure.
1) You have a sizable chunk in the southwestern part of your area that seems to have been coded as nodata (either in the DEM or resistance layer). In this funciton, GIS treats nodata pixels as essentially having an infinite resistance. (This is why that island thing has a very high distance value)
2) If you are using path distance and specifying a vertical raster but not vertical factors (or vice versa) or if any of those two parts are improperly specified or formatted, the function will simply fail to execute this portion of the tool and use the rest of the algorithm to produce output, but will not issue any warnings or indications that the vertical or horizontal direction portions of the analyses were not executed properly. Also, sometimes the program will use an ASCII vertical or horizontal factor file in some situations but not others (like it will work if using the GUI, but not python), regardless of formatting. This can make this tool difficult to troubleshoot. We usually go in and compare the distance values from a run with and without the vertical factors to see if they are different.
3) You may be able to see more detail about what the tool is doing if you run it on your test points one at a time (right now you can only view the shorter of the two distances at each pixel, since the function only records the distances from each pixel back to one of the two points in the input)
4) Without large differences in altitude across a study area and/or a wide range in weightings for the VRMA factors the output from an analysis that looks at including the cost of moving up and down a hill often just doesn't look much different from a euclidean analysis of distance. However, the numbers you get will be slightly different, and in some cases if you map the least cost paths they will take slightly different routes.
5) Technically I think you're supposed to use a z-score raster instead of a DEM as input for the vertical raster, but both are used frequently on the forums and, at least for our data, the differences in output are minimal.
ESRI's documentation on this is a little scattered, but this explanation of the vertical factors is pretty good: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost%20complexity
As mentioned in my and Tomek's comments above, this analysis can be completed by interpolating a sloping raster from either existing HEC-RAS cross sections, or by creating your own cross sections by querying your lidar surface. If you have access to the original HEC cross sections (i.e. the lines used to create the floodplain extent polygon), you can use these as contours in the Topo to Raster tool. The resulting surface will be a sloping raster that represents the floodplain inundation surface, which you can then use in your Cut/Fill calculations to determine the flood volume.
Alternatively, in the absence of the original cross section data, you can create your own cross section lines, and populate them with Z-values from your lidar surface. To do this, digitize lines perpendicular to the floodplain, terminating at the outer extents of your floodplain polygon. Create these lines at intervals sufficient to capture the variability of the down-valley slope (this approach can become fairly tedious if you have a large study area). You can then query the lidar elevation values at the intersection of your newly digitized XS lines, and use those values to populate an elevation attribute for your XS lines. Elevations at either end of your lines may not match exactly, but averaging the values should approximate the inundation surface elevation. From here you can perform the Topo to Raster and Cut/Fill analyses as mentioned above.
Best Answer
Assuming you have created surfaces from your surveys; this is a simple cut and fill operation, however you will need either a Spatial Analyst or the 3D Analyst extension to do this. (Calculates the volume change between two surfaces.)
I beleive out of the 2 extensions, Spatial Analyst is pretty much essential however the 3D analyst will allow you to also work with triangulated irregular surfaces (TINs) i addition to rasters and you can do operations such as extrude between surfaced to create 3D representations of the cut and fill volumes. To just get the numbers (volumes and areas) you just need to run cut/fill.
Screen capture from ArcGIS 10.3 help: