This behavior is not at all strange, the values being returned after coercion are the position in the factor and not the value in the vector. In a numeric vector that is, for some reason a factor, you coerce to a character then numeric ie, as.numeric(as.character(x))
Let's create a numeric vector of [0,1,5] and coerce to a factor.
class( x <- c(0,1,0,1,5,1) )
class( x <- as.factor(x) )
When we look a the factor levels you will see that the value "5" is in the third position of the factor. If we coerce straight to a numeric we will end up with [1,2,3] as the values. However, if we coerce to character first, then the values are the correct numeric values.
levels(x)
as.numeric(x)
as.numeric(as.character(x))
However, in your case the vector contains character values and cannot be coerced into a number. And, yes in looking at the error you do, in fact, have character values in this vector. You could use some of the string manipulation functions available in R but, I would suspect that since the data is an alpha-numeric identifier that, just the numeric portion is not unique.
If we introduce an alpha-numeric character into the vector, when we coerce into numeric R will return an NA coercion error and just drop the value. This is where it gets a bit dangerous using the stringsAsFactors=FALSE argument in readOGR. When you coerce you can end up with NA values that are not really NA values but rather a result of a field having some sort of non-numeric value.
(x <- as.factor(c("1","2","3","5","6L")))
as.numeric(as.character(x))
It is not entirely clear in your question but if you are wanting to sum a numeric vector based on each value in a aggregate (summary) vector. This can easily be done using tapply. In this way you can avoid sub-setting data just to get aggregate statistics.
( x <- c(rep(1,10),rep(20,10)) )
( y <- runif(20) )
tapply(y, x, sum)
If you are just after the total area of the polygons, you could sidestep this entirely and just use gArea in the rgeos package. The byid=TRUE argument will result in area(s) for each polygon.
***Update, it just occurred to me that a GIS software could be storing large numbers using scientific notation. I would imagine that this would be parsed as a character thus, resulting in a factor in R. If this is the case, these values would be erroneous when coerced. It sounds like it would be best to just get areas in R and not rely on an existing field in the data. If this is the case, and one needs a field in the data, you may have to deal with this in the software that created the data.