Does it make any sense to use inline keyword with templates?

It is not irrelevant. And no, not every function template is inline by default. The standard is even explicit about it in Explicit specialization ([temp.expl.spec])

Have the following:

a.cc

#include "tpl.h"

b.cc

#include "tpl.h"

tpl.h (taken from Explicit Specialization):

#ifndef TPL_H
#define TPL_H
template<class T> void f(T) {}
template<class T> inline T g(T) {}

template<> inline void f<>(int) {} // OK: inline
template<> int g<>(int) {} // error: not inline
#endif

Compile this, et voila:

g++ a.cc b.cc
/tmp/ccfWLeDX.o: In function `int g<int>(int)':
inlinexx2.cc:(.text+0x0): multiple definition of `int g<int>(int)'
/tmp/ccUa4K20.o:inlinexx.cc:(.text+0x0): first defined here
collect2: ld returned 1 exit status

Not stating inline when doing explicit instantiation may also lead to issues.

So in summary: For non fully specialized function templates, i.e. ones that carry at least one unknown type, you can omit inline, and not receive errors, but still they are not inline. For full specializations, i.e. ones that use only known types, you cannot omit it.

Proposed rule of thumb: Write inline if you mean it and just be consistent. It makes you think less about whether to or not to just because you can. (This rule of thumb is conforming to Vandevoorde's/Josuttis's C++ Template: The Complete Guide).

It's irrelevant. All templates are already inline- not to mention that as of 2012, the only use of the inline keyword is to stop compilers complaining about ODR violations. You are absolutely correct- your current-generation compiler will know what to inline on it's own and can probably do so even between translation units.

As you suggested, inline is a hint to the compiler and nothing more. It can choose to ignore it or, indeed, to inline functions not marked inline.

Using inline with templates used to be a (poor) way of getting round the issue that each compilation unit would create a separate object for the same templated class which would then cause duplication issues at link time. By using inline (I think) the name mangling works out different which gets round the name clash at link time but at the expense of vastly bloated code.  

Marshall Cline explains it here better than I can.