Re incrementing ids being a security risk, I'm not sure I agree - perhaps in certain circumstances, but in most cases, the authorisation for a resource is the important restriction, the identifier for the resource is arbitrary and doesn't really matter. It's only if you have sloppy authorisation that a user can then exploit incrementing ids to walk the space of resources and access them, and typically identifiers and urls are not well protected, so your url with your obscure id is just as likely to be found in email or shared and then exploited than one with an incremental id. The moonpig bug linked is an example of this - they had no authorisation in place, so random keys wouldn't have helped them, just made it harder to exploit.
Why not use UUIDs for this? They're unique so you don't have to worry about checking if an ID is already taken and you can avoid the encoding/decoding issues. There's even lexicographically sortable UUIDs (ulid) which can be a rather useful proprety and don't use any characters that can trip you up.
I would also caution against assigning meaning to names. Even though something like MEET_ or USR_ might seem innocuous such naming conventions are likely to eventually be broken. Instead make the object tell you what it is, a user vs a meeting or something else entirely.
Well technically with UUIDs you could get collision if you're using version 4 (though the chances are tiny, so it's probably not worth checking for collisions). I agree UUIDs are probably a better fit for most problems, rather than prefixing the id. Sometimes it's nice to be able to eyeball a key though and know which system it is for (stripe uses this for dev or live keys for example so they can be easily distinguished), so there are use cases for prefixes.
Re incrementing ids being a security risk, I'm not sure I agree - perhaps in certain circumstances, but in most cases, the authorisation for a resource is the important restriction, the identifier for the resource is arbitrary and doesn't really matter. It's only if you have sloppy authorisation that a user can then exploit incrementing ids to walk the space of resources and access them, and typically identifiers and urls are not well protected, so your url with your obscure id is just as likely to be found in email or shared and then exploited than one with an incremental id. The moonpig bug linked is an example of this - they had no authorisation in place, so random keys wouldn't have helped them, just made it harder to exploit.
Well technically with UUIDs you could get collision if you're using version 4 (though the chances are tiny, so it's probably not worth checking for collisions). I agree UUIDs are probably a better fit for most problems, rather than prefixing the id. Sometimes it's nice to be able to eyeball a key though and know which system it is for (stripe uses this for dev or live keys for example so they can be easily distinguished), so there are use cases for prefixes.