As stated, that policy is weird. For a true digital signature (as in RSA or ECDSA), the message to be signed is first hashed, and the rest of the operation uses the resulting hash value only. The hash computation uses only public elements; there is no key in the hash. Therefore, requiring part of the hash computation to be performed on the smartcard makes sense, security-wise, only if the smartcard may refrain from completing the signature based on what message data it gets: that is, if the smartcard could refuse the message because it does not end with a byte of value 0x5F, or any other similar arbitrary filtering rule. Such rules are pretty unusual in signing devices. Moreover, with a policy of "last block on the smartcard" and a usual hash function such as SHA-256, the smartcard only gets the last message bits (between 0 and 447 bits, depending on message length), and the total message length. That's not much for meaningful filtering rules. Without such improbable filters, requiring the last block of the message to be processed in the smartcard adds nothing at all to security.
Possibly, such a policy could be a devious fulfillment of strict legal requirements. For instance, some regulations could mandate that the hash "occurs in the smartcard" and might feel content with processing of the last block only. As an analogy, there was a time when European Union was enforcing strict quotas on car imports; a Japanese constructor then imagined to send cars without steering wheels, and also steering wheels, to a "factory" in England, where the almost-cars and the steering wheels were assembled. This was enough, according to European regulations, to make the cars "made in Europe", hence not subject to the quota.
However, there is an alternate scenario where the policy of "hashing the last block" on the smartcard makes much more sense. This is with HMAC. HMAC is for message authentication; it is not a "true" digital signature, but using the term "signature" to designate a MAC is widespread usage (though improper).
HMAC goes thus: from the secret key K are derived two block-sized values, K1 and K2 (derivation uses only a simple XOR with conventional sequences, nothing fancy, the important point being that K1 and K2 have the size of a hash function block, i.e. 64 bytes if the hash function is SHA-1 or SHA-256). Then, the MAC is computed of message m, using hash function h, as: h(K1 || h(K2 || m)).
So the bulk of the HMAC computation is basically a hash of the message m; but it must begin with the hash of a key-derived block, and there is an extra hash operation (again with another key-derived block) at the end. We do not want K1 or K2 to ever exit the smartcard (otherwise it makes little sense to use a smartcard at all). But a smartcard is not powerful (neither in CPU or I/O bandwidth) so we would prefer to perform most of the work on the external computer (in the smartcard driver). The HMAC computation would then go thus:
The driver informs the smartcard that a HMAC computation should take place; the smartcard processes K2 through the hash function and returns to the driver the hash function state achieved at that point (this leaks no usable information on K because K2 has the size of a block). Since this step does not depend on m, no real computation is needed here: the key-dependent state could have been computed once and for all when the smartcard obtained (generated) the key K in the first place.
The driver hashes m, starting with the hash function state obtained from the smartcard. The driver completes that hash computation (with padding) and sends the resulting value (which is h(K2 || m)) to the smart card.
The smartcard then computes the second hash (the one which uses K1). There again, the hash function state achieved after processing K1 could have been precalculated, so the true online work consists in processing a single hash function block.
This scenario allows for fast, externalized computation, at the speed of the host computer, while keeping the secret key in the smartcard. My guess is that when a policy of "last block in the smartcard" is advertised, they really mean a HMAC computation as I just described. This entails sloppy terminology (a MAC is not a signature) but that's still better than EU-like bureaucratic absurdity.