If you want to spend your effort on making this code cleaner, the more Julian thing would be to focus on making it more type-generic, so that it can handle arguments of more types. For example (requires Julia 0.5):
function mapeBase{T<:Number,S<:Number}(A::AbstractArray{T}, F::AbstractArray{S})
indices(A) != indices(F) && error("arguments must be arrays of the same shape")
s = zero(float(real(promote_type(T,S))))
count = 0
for i in eachindex(A)
@inbounds if A[i] != 0
s += abs((A[i] - F[i]) / A[i])
There is no performance penalty to declaring more generic function argument types. When you pass in Vector{Float64} arrays, a version of mapeBase is specialized to that type and compiled, just as if you had declared those types.
Note, by the way, that this way of comparing two arrays is very susceptible to floating-point roundoff errors — think about what happens if A[i] is supposed to be 0.0, but is actually 1e-15 due to roundoff. I would normally recommend something like vecnorm(A - F, 1) / vecnorm(A, 1) instead -- i.e. take the sum of the |A[i] - F[i]| and divide by the sum of |A[i]|.
I agree with other posters that this is a case in which a loop is much cleaner. It is possible to solve this problem efficiently with reduce in 0.5 (where higher-order functions are now fast), but it would require much more careful coding and the resulting code would be much more obscure and unmaintainable, nor would a reduce-based implementation be much shorter as you have seen.
Higher-order functions are great, and it is great to use them where they simplify your code. But sometimes a loop is cleaner, and (unlike in other dynamic languages) there is no reason not to use loops in Julia.