What is compile-time polymorphism and why does it only apply to functions?

The thing which only applies to functions is template parameter deduction. If I have a function template:

template <typename T> 
void foo(T &t);

Then I can do int a = 0; foo(a);, and this will be equivalent to int a = 0; foo<int>(a);. The compiler works out that I mean foo<int>. At least, it works out that it should use foo<int> - if that's not what I meant then bad luck to me, and I could have written foo<unsigned int>(a); or whatever.

However, if I have a class template:

template <typename T>
struct Foo {
    T &t;
    Foo(T &t) : t(t) {}
    T &getT() { return t; }
};

Then I can't do int a = 0; Foo(a).getT();. I have to specify Foo<int>(a). The compiler isn't allowed to work out that I mean Foo<int>.

So you might say that class templates are "less polymorphic" than function templates. Polymorphism usually means that you don't have to write code to make the type of your object explicit. Function templates allow that (in this particular case), and class templates don't.

As for why this is the case - the standard says so, I don't know why. The usual suspects are (a) it's too difficult to implement, (b) it's not useful, in the opinion of the standard committee, or (c) it creates some contradiction or ambiguity somewhere else in the language.

But you can still do other kinds of polymorphism with classes:

template <typename T>
struct Foo {
    T &t;
    Foo(T &t): t(t) {}
    void handleMany(int *ra, size_t s) {
        for (size_t i = 0; i < s; ++i) {
            t.handleOne(ra[i]);
        }
    }
};

This is usually also called compile-time polymorphism, because as far as the author of the template is concerned, t.handleOne could be anything, and what it is will be resolved when necessary, "later" in the compilation when Foo is instantiated.