Ended up making a "LinkButtonBlock" like this. Not ideal, but it does the job.

    [ContentType(
        DisplayName = "Link Button Block",
        GUID = "31B4F4E4-3615-4242-A3E0-68E35DCDDD0B")]
    public class LinkButtonBlock : BaseBlock
    {
        [Display(
            Name = "Text",
            Description = "",
            GroupName = SystemTabNames.Content,
            Order = 110)]
        [CultureSpecific]
        public virtual string Text { get; set; }

        [Display(
            Name = "Link",
            Description = "",
            GroupName = SystemTabNames.Content,
            Order = 120)]
        [CultureSpecific]
        public virtual Url Link { get; set; }
    }

Unfortunately, it's probably the best way to go right now. The link property has never had the ability to save additional parameters except for the URL. You could add a property that handles LinkItems but my hunch is that it would require some work since you need to create both a client editor (that uses the built in link dialog) as well as serializing the LinkItem.

It's confusing and flicks do not have this problem, but it's not easy to tell ahead of time. DIRECTV Sign In Last night, I terminated up the application on my Android phone. 

We have run into this architectureal question many times. Creating a block doesn't make sense. Imagine as an author you have to create a block for every single link you want to add to the Content Area.

We ended up using Property List that allows it to be more configurable and the authors can edit all links in one place. Refer to the explaination from Per here:

https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2015/11/trying-out-propertylistt/

The only catch here is it is not very on Page editor friendly but it's a tradeoff that I am fine living with.

 [ContentType(DisplayName = "Career CTA Grid Block", GUID = "f0548176-65bb-4176-a34d-9cae5ea6aef0", Description = "Career CTA 3 Column Grid block")]
    public class CareerCTAGridBlock : SiteBlockData
    {
        [Display(
            Name = "Careers CTA Grid",
            Description = "Careers CTA Grid",
            GroupName = SystemTabNames.Content,
            Order = 200)]
        [EditorDescriptor(EditorDescriptorType = typeof(CollectionEditorDescriptor<CareersCTA>))]
        public virtual IList<CareersCTA> CareersCTAItems { get; set; }
    }

    public class CareersCTA
    {
        [UIHint(UIHint.Image)]
        public ContentReference Image { get; set; }
        
        [Display(Name = "Title")]
        [Required]
        [UIHint(UIHint.LongString)]
        public string Title { get; set; }

        [UIHint(UIHint.Textarea)]
        [Display(Name = "Teaser Text")]
        public string Teaser { get; set; }

        [Display(Name = "CTA Link Text")]
        public string CTALinkText { get; set; }

        [Display(Name = "CTA Link")]
        [Required]
        public Url CTALink { get; set; }

    }

    [PropertyDefinitionTypePlugIn]
    public class CareersCTAProperty : PropertyList<CareersCTA>
    {
        protected override CareersCTA ParseItem(string value)
        {
            return JsonConvert.DeserializeObject<CareersCTA>(value);
        }
        public override PropertyData ParseToObject(string value)
        {
            ParseToSelf(value);
            return this;
        }
    }

Creating a block doesn't make sense

I guess Torjus solved it by a local block so need for a ContentArea.

No need*? :) 

Local blocks in my experience is a bit confusing, feels like you're mixing two concepts. I'd use local blocks just Torjus does, simply grouping content properties for re use on different content types. But seeing as you can add block controllers and ultimately use this block in a contentarea, making it IContent, simply to me seems as a risk as the two ways of working with blocks are so different.

I agree the best use case for local blocks is grouping properties.

In this case having a better A-element editor that was shared between TinyMCE and the link property type would be the best fit I think. Follow the HTML5 spec and be sure not to miss adding a REL-attribute field.