That is nasty, indeed. At least with pdf output (the resulting bounding box of the image is also used to clip the image). It might work better with ps output (I do not know).
I guess the only solution is to increase the size of the bounding box manually. In your example, you could use
\useasboundingbox (-0.2,-0.2);
as last statement (otherwise it would overwrite the entire bounding box). In our case, we simply "append" the (-0.2,-0.2) coordinate to the picture's bounding box.
This alters your image's bounding box, of course. That is probably what you want. If not, you might be interested in the following part of the answer.
A solution which keeps the current bounding box would be to rely on trim left, trim right, and baseline to undo the effects of \useasboundingbox.
Here is a possible approach:
\documentclass{report}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\begin{document}
\thispagestyle{empty}
\fboxsep=0pt
\dotfill
\fbox{%
\begin{tikzpicture}[trim left=0pt,trim right=5cm,baseline]
\draw[->,ultra thick] (0,0) -- (0,5);
\draw[->,ultra thick] (0,0) -- (5,0);
\useasboundingbox (-0.2,-0.2);
\end{tikzpicture}%
}
\dotfill
\end{document}

as you guessed correctly, the \fboxsep, \dotfill, and \fbox stuff is just syntactical sugar to verify that it works. The key idea is trim left,trim right,baseline combined with \useasboundingbox.
The first two keys allow to modify the bounding box of a picture and the third key controls vertical displacement. However, unlike the "tight" bounding box produced by the external lib, the resulting image has a larger bounding box than the trim values. The trim values are implemented by means of negative \hspaces and are also applied by the external lib. The baseline thing simply moves the complete image vertically; that appears to be enough.
arrows.metalibrary solves the problem. See: http://tex.stackexchange.com/a/321854/1952 – Ignasi Aug 01 '16 at 08:40