First, let's clear up a misconception. There is no such thing as a "server-side cookie." While a server can send cookies with an HTTP response, there is no server-side cache of valid cookies. That is a construct that only exists on the client side in a user agent (such as a browser) that supports it. This is what makes cookies powerful. You can maintain state for thousands, or hundreds of thousands of users (or more!) and the only resources required are a little bit of memory and storage on each client machine, and none at all on the server side. The only knowledge a server needs to have of a cookie is how to parse it out of a request, and how to set it (if required) on a response.
Now, let's talk about Forms Authentication specifically. Forms Auth is a purely cookie-based authentication mechanism. (For the sake of simplicity and to focus on the question at hand, I'm going to leave cookieless-FormsAuth out.) This means that you have a simple, light-weight, easy to configure authentication mechanism that requires little in the way of server resources and no shared server-side state management process and overhead.
What this also means, is that when you send that original authentication ticket to the client, for as long at that ticket is valid, it can be used to authenticate future requests. No change that you make (expiring the cookie, setting additional expiration information in a new ticket and replacing the cookie, adding additional "logged out" cookies" can prevent the original cookie from being used as long as it is valid.
Is this a problem? In practice, not usually. For most applications, this does not create a specific threat that needs to be mitigated and the ability to authenticated users without being tied to a server-side resource investment requirement is quite attractive. If you can't quantify the value of adding the additional mitigation of server-side session invalidation for your application, then implementing it is a net loss, not a desirable outcome.
If the threat model for you application does demonstrate a specific reason to need to securely de-authenticate sessions, then bare Forms Authentication is not for you, and you need to implement a server-side session validation mechanism on top of it track authentication state to determine which users are valid authenticated users and drop requests from all others, regardless of the nominal validity of the authentication ticket submitted with a forms auth cookie.
Lastly, do other frameworks work this way? Certainly many do. This is a necessary property of any stateless authentication system that is relying on a ticket submitted by a client to determine authentication state, and that's probably more authentication mechanisms than not. Authentication systems that have a server-side session management component can avoid this by tracking authentication state server-side, whether any given system does it correctly is up to the reader to test. Not as germane but worth mentioning...Not all authentication systems have the concept of signing out in the first place. If you're using certificate authentication, or integrated authentication, for instance, there is really no concept of "signing out" and transition back from an authenticated to an unauthenticated state, and in these cases the issue is irrelevent.