AccountLockoutCounterResetEnabled attribute clarification

Hi,
As per schema AccountLockoutCounterResetEnabled is defined as below

"AccountLockoutCounterResetEnabled": {
"description": "The value indicates whether the threshold counter will be reset after AccountLockoutCounterResetAfter expires.",
"longDescription": "This property shall indicate whether the threshold counter will be reset after the AccountLockoutCounterResetAfter has expired. Setting the value to false shall indicate that only a successful login will reset the threshold counter. In addition, if the user reaches the limit specified in AccountLockoutThreshold, the account shall be locked out indefinitely and only a reset by administrator will clear the threshold counter. If this property is absent the value shall be assumed to be true.",
"readonly": false,
"type": "boolean",
"versionAdded": "v1_5_0"
} 
Assume use case like only one Administrator account is there and no other additional account/external authentication mechanism available, User patching AccountLockoutCounterResetEnabled to false, then he used wrong password for five times(AccountLockoutThreshold limit is 5) and Account will get locked.
In this case there is no other account available to reset. Since this is user initiated operation, do we need to block changing AccountLockoutCounterResetEnabled when there is only one administrator account (user can create two users and set AccountLockoutCounterResetEnabled  to false for administrator, then delete one account) or allow invalid login attempts without locking(This can create a attack to try different password)

Can we get more details about using AccountLockoutCounterResetEnabled in these types of situation. Also as per manager Account xml(ManagerAccount_v1.xml), we need to allow delete any account. 


<Annotation Term="Capabilities.DeleteRestrictions">
<Record>
<PropertyValue Property="Deletable" Bool="true"/>
<Annotation Term="OData.Description" String="Manager Accounts are removed with a Delete operation."/>
</Record>
</Annotation


so in this case we can't block user to delete default account. Do we have any fixed user concepts to avoid these type of situations?

Thanks,
Mani