Programming chess engines is very complicated territory, so right up front I'll point you to the Chess Programming Wiki, which has a lot of great information on this topic.
Chess calculations (and many similar things) are generally modeled and thought of as "game trees" or "decision trees". Broadly, this tree is a directed graph, with one node at the top (the current position), leading to a node for each possible move, each of which leads to more nodes for each possible next move, and so on.
In their most simplistic, brute-force form, Chess engines generate all positions on this tree down to some depth limit ("ply"), evaluating each resulting position based on some complex criteria1. Then it plays the move that seems to lead to the best result. Nowadays, a lot of really complicated techniques have been developed to limit the number of positions that the engine has to look at, but I'm going to ignore those for the purpose of this answer, because they don't change the real issue at hand.
The basic reason that engines typically take about the same amount of time to consider each move is that the size of the decision tree increases exponentially with depth (
Consider the starting position. The top of the tree (
k=0) is one node. There are twenty possible first moves for White, so there are twenty nodes at depth
k=1. Then, Black also has twenty available moves for each of White's options: so at
k=2, there are
20 * 20 = 400 possible positions! And it only gets worse as the players develop their pieces!
For example, let's pretend that there are always twenty possible moves for each player at any given time2. You instruct the computer to look ahead five moves for each player (ten ply).
Let's look at the size of the brute-force tree at each level. For fun, we'll also look at the total number of positions in the tree (from the top to the given level).
Ply | Positions | Total Tree Size
0 | 1 | 1
1 | 20 | 21
2 | 400 | 421
3 | 8000 | 8421
4 | 160000 | 168421
5 | 3200000 | 3368421
6 | 64000000 | 67368421
7 | 1280000000 | 1347368421
8 | 25600000000 | 26947368421
9 | 512000000000 | 538947368421
10 | 10240000000000 | 10778947368421
The result of each level being exponentially larger than the previous level is that the size of the whole tree is dominated by the bottom level. Consider the example above: the last level alone contains ten trillion nodes. The entire rest of the tree only contains five hundred billion. The tenth ply contains about 95% of the nodes in the entire tree (this is actually true at each level). In practice, what this means is that all of the search time is spent evaluating the "last" move.
So how does this relate to your question? Well, let's say the computer is set to ten ply, as above, and further it "remembers" the results of its evaluations. It calculates a move, plays it, and then you make a move. Now two moves have been made, so it prunes all the positions from memory related to the moves that didn't happen, and is left with a tree that goes down the remaining eight moves that it already calculated: 26,947,368,421 positions!
All right! So we only need to calculate the last two ply! Using our 20-moves-at-each-depth estimate, the total number of moves we need to calculate here is still over ten trillion. The positions we already calculated only account for 2.5% of the possibilities! So even by caching last move's results, the best we can hope for is a 2.5% increase in speed! At heart, this is why even if your program caches previous results, you don't usually see a significant speedup between moves (excepting cases when the computer finds a forced mate or something, of course!).
There is a lot of complexity involved in this question, which is why I linked to the programming wiki at the very top and only attempted to explain the answer in broad mathematical terms. In reality, programs do generally cache parts of the tree from move to move, and there are other reasons why that's insufficient on its own--some simple reasons (e.g. a certain line might look good out to eight moves, but ends with a back-rank mate on move nine!) and many highly complicated ones (generally related to various clever pruning methods). So the computer must keep looking further ahead in an attempt to avoid making bad assumptions based on the previous move's cut-off depth.
1I'm not going to get into heuristic functions here, because that's its own incredibly complex area, but there are frequently some gains that can be achieved via position caching schemes here as well.
2An average branching factor of 20 is probably much too low.