If you start with an array [A,B,C,D,E,F,G] and you delete "D", then you will have an array [A,B,C,nothing,E,F,G]. It's no shorter than before.
Given that the blockchain is immutable, nothing like an actual "delete" is possible. For example, delete won't prevent accidental disclosure. It's too late because the previous value is part of the immutable history.
Applications often have a need for some sort of logical delete. A common approach is to set a bit
isValid in a struct to help differentiate between mapped values that merely default to
0 and actual set values that are explicitly
0. It's also common to maintain a list keys to a
mapping so iteration is possible. In the case where a majority of keys will be deleted, then one will want to collect garbage and control the size of the key list.
One approach is to treat the list as "unordered", move the last item in the list to the row to delete, and then decrement the list size by 1. This approach ensures a fixed gas cost for the delete operation at any scale. The intuitive idea of reorganizing the array to "remove" the deleted slot but otherwise maintain the order is prohibitively expensive at scale because it involves SSTORE operations for every row "above" the row to delete.
Explained in more detail, here: https://medium.com/@robhitchens/solidity-crud-part-2-ed8d8b4f74ec
Hope it helps.