I think this is due to how axis lines are drawn and seems to me a candidate as a bug. Consider the following;
\documentclass{article}
\usepackage{pgfplots}
\begin{document}
\begin{tikzpicture}[mydeco/.style={
decoration={%
random steps, % CRITICAL LINE
segment length=1mm,
amplitude=1pt,#1,
post length=10mm,
post= lineto % Change to " moveto "!
},
decorate,
}
]
\begin{axis}[%
line width=1pt,
axis lines*=middle,
every inner x axis line/.style={->,mydeco},
every inner y axis line/.style={->,mydeco},
]
\begin{scope}[mydeco={segment length=3pt,amplitude=0.5pt},decorate]
\addplot [blue,samples=50, domain=0:120,->] {(2479*x^6)/5513508000000-(13697*x^5)/61261200000+(7935509*x^4)/220540320000-(1889983*x^3)/816816000+(2038007*x^2)/40840800+(335201*x)/1021020};
\end{scope}
\end{axis}
\draw[mydeco,->,red,ultra thick] (0,0) -- (5,6);
\end{tikzpicture}
\end{document}

Here I tried to stop the decoration 10mm before the path end. It is OK for paths but not for axis lines. This means there is a move operation somewhere that changes the current path such that post length and post path drawing mechanism is not applied to the axis line. As an example change lineto to moveto and we can replicate that behavior on other paths too.
I will attempt to have a look but that part of the code is really involved due to 3D/2D settings. Maybe Christian can help here. Otherwise we can open a ticket. Then randomized paths would have the arrow head automatically without any post=... tweak.
It turns out that this behaviour is due to a missing expansion in an internal PGFPlots macro. PGFPlots uses a decoration to place axis discontinuity marks, which requires setting pre length and post length values for the decoration. PGFPlots sets pre length and post length using macros (called \xdisstart, \xdisend, etc.). If no discontinuity is used, these macros are set to 0pt. However, for some reason, arrow tips aren't placed correctly when the pre length and post length values contain unexpanded macros. So in order to fix the behaviour, you can redefine an internal PGFPlots macro by placing the following code in your preamble:
\makeatletter
\def\pgfplots@drawaxis@innerlines@onorientedsurf#1#2#3{%
\if2\csname pgfplots@#1axislinesnum\endcsname
\draw[/pgfplots/every inner #1 axis line,%
decorate,%
#1discont,%
decoration={% Expand the macros before setting the values
pre length/.expand twice=\csname #1disstart\endcsname,
post length/.expand twice=\csname #1disend\endcsname
}
]
\pgfextra
\csname pgfplotspointonorientedsurfaceabsetupforset#3\endcsname{\csname pgfplots@logical@ZERO@#3\endcsname}{2}%
\pgfpathmoveto{\pgfplotspointonorientedsurfaceab{\csname pgfplots@#1min\endcsname}{\csname pgfplots@logical@ZERO@#2\endcsname}}%
\pgfpathlineto{\pgfplotspointonorientedsurfaceab{\csname pgfplots@#1max\endcsname}{\csname pgfplots@logical@ZERO@#2\endcsname}}%
\endpgfextra
;
\fi
}%
\makeatother

\pgfplots@drawaxis@innerlines@onorientedsurfinpgfplots.code.tex, which draws the axis lines when usingaxis lines=middle. In the\drawcommand, theevery inner #1 axis linestyle is followed by a hard codeddecorationfor the axis discontinuity, which setspost length=\csname #1disend\endcsname.\xdisendhappens to be0ptwhen no discontinuity is used, which causes the arrow head problem. The problem can be fixed somewhat heavy-handedly by settingxdisend/.store in=\xdisend,xdisend=1bpin theevery inner x axis line/.style. – Jake Feb 18 '14 at 09:56postrelated stuff from the style). Hence, there is additional action after the axis lines are plotted. Maybe the if conditions are disrupting by installing empty paths. I can see some relevant stuff but I don't exactly understand what those conditions do. – percusse Feb 18 '14 at 11:44\csname #1disend\endcsnamenot being expanded. Ifpre length=\csname #1disstart\endcsname, post length=\csname #1disend\endcsnameis replaced withpre length/.expand twice=\csname #1disstart\endcsname, post length/.expand twice=\csname #1disend\endcsname, the arrow heads are placed correctly, even without specifying apost length. Don't ask me why that happens, though. Maybe this would be worth opening a bug report for. – Jake Feb 18 '14 at 12:23