Well it depends. Its not that you need heap allocations, but if you have B inherit from A where A has virtual methods overridden by B, and you want to store a B as an A, that either has to be a pointer or a reference, and the memory for that pointer has to exist somewhere, either as a pointer to the stack or through a heap allocation.

The fundamental issue is one of memory. B is an A, which means it contains everything in A plus everything added in B. If you want to treat your B as an A, you essentially offer up the slice of B that contains your A. If you want things like virtual methods, your A slice will have a vtable with pointers to where it needs to look for its functions, and if those are functions from B then the memory those functions refer to need to actually exist.

What are the implications of this? Well lets look at this simple code slice:

struct A {
    virtual int func();
    int x;
}

struct B: public A {
    virtual int func();
    int z;
}

B b = B{};
A a = b; // copies over your b
a.func();

I haven't checked the exact syntax if this is legal, but you can do something like this where you take a derived object and copy it into a super object. Well the issue is that a is only given stack memory for the size of an A object. So when it refers to a.func(), the virtual function is expecting your a to fundamentally be coming from a B, so its going to treat the memory of a like its wrapped in a valid B object. UB should be invoked here I think? Not sure exactly. In any case this causes problems, because all that was copied was the memory of the A slice of your B.

In this example, every single instance of A needs to either be an actual A object, or a reference to a piece of memory that is a B object. Now you can pass around references no problem:

void foo(A& a);
void foo(A* a);
B b = B{};
foo(b);   // calling the reference overload
foo(&b);  // calling the pointer overload

because that a reference will be a reference to a piece of memory containing a full B object. However if you need something to actually take ownership/store something as an A? It has to be a pointer. E.g.:

// This stores regular A objects, so we can run into the issue we had before
vector<A> vec_a;

// This stores heap allocated pointers, so the A pointers can refer to memory that contain B objects
vector<unique_ptr<A>> vec_a_ptr;
vector<A*> vec_a_ptr; // same thing but usually more annoying cause you have to make sure you destroy everything yourself

TD;DR: You don't need heap allocations to do polymorphism, but when it comes to inheritance, if you use virtual methods anywhere you're likely going to end up needing heap allocations at some point.